[RFT] GCC 8.1

[RFT] GCC 8.1

[Khem Raj]

Hi All

As you might have noticed that gcc 8.1 was released this week, I am
calling out for some testing help on testing branch so we can weed out
issues you might see in your setups. so if you have your
builders idling over weekend, then you know what they can do this weekend :)

Highlighted changes are

https://gcc.gnu.org/gcc-8/changes.html

and porting doc is

https://gcc.gnu.org/gcc-8/porting_to.html

The branch is here

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8

Its uptodate on top of current master oe-core

May fourth be with you !!

Cheers!

-Khem

Re: [RFT] GCC 8.1

[Zoran Stojsavljevic]

> May fourth be with you !!

@off topic!

Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-)

Zoran
_______

On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: [RFT] GCC 8.1

[Khem Raj]

On 5/5/18 12:31 AM, Zoran Stojsavljevic wrote:
>> May fourth be with you !!
> 
> @off topic!
> 
> Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-)

Well the message was sent on "may 4th" hence it was meant to be a 
light-hearted encouragement to test the patchset

> 
> Zoran
> _______
> 
> On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFT] GCC 8.1

[Khem Raj]

On 5/5/18 12:31 AM, Zoran Stojsavljevic wrote:
>> May fourth be with you !!
> 
> @off topic!
> 
> Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-)

Well the message was sent on "may 4th" hence it was meant to be a 
light-hearted encouragement to test the patchset

> 
> Zoran
> _______
> 
> On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]

My initial tests show couple issues, but usually caused by other changes in
that branch, not the gcc-8 itself.

1) strace-4.22 from
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
fails to build with ptest enabled (it builds with 4.20 version if I revert
this change)
../../strace-4.22/tests/inject-nf.c: In function 'main':
../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm
here
 }
 ^
Makefile:6313: recipe for target 'inject-nf.o' failed
make: *** [inject-nf.o] Error 1
make: Leaving directory 'strace/4.22-r0/build/tests'

2) glibc with obsolete rpc disabled from:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
causes busybox's mount applet to fail building:
util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
 # include <rpc/rpc.h>
           ^~~~~~~~~~~
compilation terminated.
make[1]: *** [util-linux/mount.o] Error 1
make: *** [util-linux] Error 2

3) grub and grub-efi fails to build with gcc8:
In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
..
../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct
grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^

4) iotivity fails to build with gcc8:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:
In lambda function:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30:
error: 'value' is not captured
                 ocRep[KEY] = value;
                              ^~~~~

5) nativesdk-libxcrypt fails to build (not sure which change caused this,
it build OK with sumo since the -std=gnu99 addition.
../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
before the last format character [-Werror=format-truncation=]
             "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
             ^~~

6) couple internal components which usually fail to build with gcc8,
because of more strict warnings + Werror.

I didn't get very far in testing, because our old kernel fails to build
with gcc8 and there are some other issues caused by other master changes.
But it doesn't look too bad (in my small test, lets see what bitbake world
will show), thanks a lot for new gcc.

Cheers,





On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote:

> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend
> :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 11610 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

My initial tests show couple issues, but usually caused by other changes in
that branch, not the gcc-8 itself.

1) strace-4.22 from
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
fails to build with ptest enabled (it builds with 4.20 version if I revert
this change)
../../strace-4.22/tests/inject-nf.c: In function 'main':
../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm
here
 }
 ^
Makefile:6313: recipe for target 'inject-nf.o' failed
make: *** [inject-nf.o] Error 1
make: Leaving directory 'strace/4.22-r0/build/tests'

2) glibc with obsolete rpc disabled from:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
causes busybox's mount applet to fail building:
util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
 # include <rpc/rpc.h>
           ^~~~~~~~~~~
compilation terminated.
make[1]: *** [util-linux/mount.o] Error 1
make: *** [util-linux] Error 2

3) grub and grub-efi fails to build with gcc8:
In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
..
../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct
grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^

4) iotivity fails to build with gcc8:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:
In lambda function:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30:
error: 'value' is not captured
                 ocRep[KEY] = value;
                              ^~~~~

5) nativesdk-libxcrypt fails to build (not sure which change caused this,
it build OK with sumo since the -std=gnu99 addition.
../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
before the last format character [-Werror=format-truncation=]
             "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
             ^~~

6) couple internal components which usually fail to build with gcc8,
because of more strict warnings + Werror.

I didn't get very far in testing, because our old kernel fails to build
with gcc8 and there are some other issues caused by other master changes.
But it doesn't look too bad (in my small test, lets see what bitbake world
will show), thanks a lot for new gcc.

Cheers,





On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote:

> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend
> :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]

My initial tests show couple issues, but usually caused by other changes in
that branch, not the gcc-8 itself.

1) strace-4.22 from
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
fails to build with ptest enabled (it builds with 4.20 version if I revert
this change)
../../strace-4.22/tests/inject-nf.c: In function 'main':
../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm
here
 }
 ^
Makefile:6313: recipe for target 'inject-nf.o' failed
make: *** [inject-nf.o] Error 1
make: Leaving directory 'strace/4.22-r0/build/tests'

2) glibc with obsolete rpc disabled from:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
causes busybox's mount applet to fail building:
util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
 # include <rpc/rpc.h>
           ^~~~~~~~~~~
compilation terminated.
make[1]: *** [util-linux/mount.o] Error 1
make: *** [util-linux] Error 2

3) grub and grub-efi fails to build with gcc8:
In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
..
../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct
grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^

4) iotivity fails to build with gcc8:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:
In lambda function:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30:
error: 'value' is not captured
                 ocRep[KEY] = value;
                              ^~~~~

5) nativesdk-libxcrypt fails to build (not sure which change caused this,
it build OK with sumo since the -std=gnu99 addition.
../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
before the last format character [-Werror=format-truncation=]
             "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
             ^~~

6) couple internal components which usually fail to build with gcc8,
because of more strict warnings + Werror.

I didn't get very far in testing, because our old kernel fails to build
with gcc8 and there are some other issues caused by other master changes.
But it doesn't look too bad (in my small test, lets see what bitbake world
will show), thanks a lot for new gcc.

Cheers,





On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote:

> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend
> :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 11610 bytes --]

[PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Martin Jansa]

* We dropped in-tree obsoleted rpc from glibc and now busybox builds
  which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with:
  | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
  |  # include <rpc/rpc.h>
  |            ^~~~~~~~~~~
  | compilation terminated.
  | make[1]: *** [util-linux/mount.o] Error 1

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/recipes-core/busybox/busybox.inc       | 6 +++---
 meta/recipes-core/busybox/busybox/defconfig | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index d1675c37aa..2db19ed317 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into
 HOMEPAGE = "http://www.busybox.net"
 BUGTRACKER = "https://bugs.busybox.net/"
 
-DEPENDS += "kern-tools-native"
+DEPENDS += "kern-tools-native libtirpc"
 
 # bzip2 applet in busybox is based on lightly-modified bzip2 source
 # the GPL is version 2 only
@@ -15,8 +15,8 @@ SECTION = "base"
 # Whether to split the suid apps into a seperate binary
 BUSYBOX_SPLIT_SUID ?= "1"
 
-export EXTRA_CFLAGS = "${CFLAGS}"
-export EXTRA_LDFLAGS = "${LDFLAGS}"
+export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc"
+export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc"
 
 EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'"
 
diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig
index fbb5fd852c..816555fc21 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -638,7 +638,7 @@ CONFIG_MOUNT=y
 # CONFIG_FEATURE_MOUNT_VERBOSE is not set
 # CONFIG_FEATURE_MOUNT_HELPERS is not set
 # CONFIG_FEATURE_MOUNT_LABEL is not set
-# CONFIG_FEATURE_MOUNT_NFS is not set
+CONFIG_FEATURE_MOUNT_NFS=y
 # CONFIG_FEATURE_MOUNT_CIFS is not set
 CONFIG_FEATURE_MOUNT_FLAGS=y
 CONFIG_FEATURE_MOUNT_FSTAB=y
-- 
2.17.0

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Burton, Ross]

Fails to build here:

 coreutils/lib.a(mktemp.o): In function `mktemp_main':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105:
warning: the use of `mktemp' is dangerous, better use `mkstemp' or
`mkdtemp'
| util-linux/lib.a(mount.o): In function `xdr_fhstatus':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057:
undefined reference to `xdr_u_int'
| util-linux/lib.a(mount.o): In function `xdr_fhandle':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052:
undefined reference to `xdr_opaque'
| util-linux/lib.a(mount.o): In function `xdr_mountstat3':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089:
undefined reference to `xdr_enum'
| util-linux/lib.a(mount.o): In function `xdr_fhandle3':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071:
undefined reference to `xdr_bytes'
| util-linux/lib.a(mount.o): In function `xdr_mountres3_ok':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
undefined reference to `xdr_int'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
undefined reference to `xdr_array'
| util-linux/lib.a(mount.o): In function `xdr_dirpath':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066:
undefined reference to `xdr_string'
| util-linux/lib.a(mount.o): In function `get_mountport':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145:
undefined reference to `pmap_getmaps'
| util-linux/lib.a(mount.o): In function `nfsmount':
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662:
undefined reference to `clnttcp_create'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677:
undefined reference to `authunix_create_default'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652:
undefined reference to `clntudp_create'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672:
undefined reference to `clnt_spcreateerror'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702:
undefined reference to `clnt_sperror'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707:
undefined reference to `clnt_sperror'
| /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788:
undefined reference to `pmap_getport'

Ross

On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> * We dropped in-tree obsoleted rpc from glibc and now busybox builds
>   which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with:
>   | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
>   |  # include <rpc/rpc.h>
>   |            ^~~~~~~~~~~
>   | compilation terminated.
>   | make[1]: *** [util-linux/mount.o] Error 1
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  meta/recipes-core/busybox/busybox.inc       | 6 +++---
>  meta/recipes-core/busybox/busybox/defconfig | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
> index d1675c37aa..2db19ed317 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into
>  HOMEPAGE = "http://www.busybox.net"
>  BUGTRACKER = "https://bugs.busybox.net/"
>
> -DEPENDS += "kern-tools-native"
> +DEPENDS += "kern-tools-native libtirpc"
>
>  # bzip2 applet in busybox is based on lightly-modified bzip2 source
>  # the GPL is version 2 only
> @@ -15,8 +15,8 @@ SECTION = "base"
>  # Whether to split the suid apps into a seperate binary
>  BUSYBOX_SPLIT_SUID ?= "1"
>
> -export EXTRA_CFLAGS = "${CFLAGS}"
> -export EXTRA_LDFLAGS = "${LDFLAGS}"
> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc"
> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc"
>
>  EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'"
>
> diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig
> index fbb5fd852c..816555fc21 100644
> --- a/meta/recipes-core/busybox/busybox/defconfig
> +++ b/meta/recipes-core/busybox/busybox/defconfig
> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y
>  # CONFIG_FEATURE_MOUNT_VERBOSE is not set
>  # CONFIG_FEATURE_MOUNT_HELPERS is not set
>  # CONFIG_FEATURE_MOUNT_LABEL is not set
> -# CONFIG_FEATURE_MOUNT_NFS is not set
> +CONFIG_FEATURE_MOUNT_NFS=y
>  # CONFIG_FEATURE_MOUNT_CIFS is not set
>  CONFIG_FEATURE_MOUNT_FLAGS=y
>  CONFIG_FEATURE_MOUNT_FSTAB=y
> --
> 2.17.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Khem Raj]

On 5/10/18 6:01 AM, Burton, Ross wrote:
> Fails to build here:
> 
>   coreutils/lib.a(mktemp.o): In function `mktemp_main':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105:
> warning: the use of `mktemp' is dangerous, better use `mkstemp' or
> `mkdtemp'
> | util-linux/lib.a(mount.o): In function `xdr_fhstatus':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057:
> undefined reference to `xdr_u_int'
> | util-linux/lib.a(mount.o): In function `xdr_fhandle':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052:
> undefined reference to `xdr_opaque'
> | util-linux/lib.a(mount.o): In function `xdr_mountstat3':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089:
> undefined reference to `xdr_enum'
> | util-linux/lib.a(mount.o): In function `xdr_fhandle3':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071:
> undefined reference to `xdr_bytes'
> | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
> undefined reference to `xdr_int'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
> undefined reference to `xdr_array'
> | util-linux/lib.a(mount.o): In function `xdr_dirpath':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066:
> undefined reference to `xdr_string'
> | util-linux/lib.a(mount.o): In function `get_mountport':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145:
> undefined reference to `pmap_getmaps'
> | util-linux/lib.a(mount.o): In function `nfsmount':
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662:
> undefined reference to `clnttcp_create'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677:
> undefined reference to `authunix_create_default'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652:
> undefined reference to `clntudp_create'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672:
> undefined reference to `clnt_spcreateerror'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702:
> undefined reference to `clnt_sperror'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707:
> undefined reference to `clnt_sperror'
> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788:
> undefined reference to `pmap_getport'
> 

We need to specify

CONFIG_EXTRA_LDLIBS="tirpc"

along with

CONFIG_FEATURE_MOUNT_NFS=y

secondly in v2 please delete

# CONFIG_FEATURE_MOUNT_NFS is not set

from meta/recipes-core/busybox/busybox/musl.cfg as well

> Ross
> 
> On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote:
>> * We dropped in-tree obsoleted rpc from glibc and now busybox builds
>>    which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with:
>>    | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
>>    |  # include <rpc/rpc.h>
>>    |            ^~~~~~~~~~~
>>    | compilation terminated.
>>    | make[1]: *** [util-linux/mount.o] Error 1
>>
>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>> ---
>>   meta/recipes-core/busybox/busybox.inc       | 6 +++---
>>   meta/recipes-core/busybox/busybox/defconfig | 2 +-
>>   2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
>> index d1675c37aa..2db19ed317 100644
>> --- a/meta/recipes-core/busybox/busybox.inc
>> +++ b/meta/recipes-core/busybox/busybox.inc
>> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into
>>   HOMEPAGE = "http://www.busybox.net"
>>   BUGTRACKER = "https://bugs.busybox.net/"
>>
>> -DEPENDS += "kern-tools-native"
>> +DEPENDS += "kern-tools-native libtirpc"
>>
>>   # bzip2 applet in busybox is based on lightly-modified bzip2 source
>>   # the GPL is version 2 only
>> @@ -15,8 +15,8 @@ SECTION = "base"
>>   # Whether to split the suid apps into a seperate binary
>>   BUSYBOX_SPLIT_SUID ?= "1"
>>
>> -export EXTRA_CFLAGS = "${CFLAGS}"
>> -export EXTRA_LDFLAGS = "${LDFLAGS}"
>> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc"
>> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc"
>>
>>   EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'"
>>
>> diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig
>> index fbb5fd852c..816555fc21 100644
>> --- a/meta/recipes-core/busybox/busybox/defconfig
>> +++ b/meta/recipes-core/busybox/busybox/defconfig
>> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y
>>   # CONFIG_FEATURE_MOUNT_VERBOSE is not set
>>   # CONFIG_FEATURE_MOUNT_HELPERS is not set
>>   # CONFIG_FEATURE_MOUNT_LABEL is not set
>> -# CONFIG_FEATURE_MOUNT_NFS is not set
>> +CONFIG_FEATURE_MOUNT_NFS=y
>>   # CONFIG_FEATURE_MOUNT_CIFS is not set
>>   CONFIG_FEATURE_MOUNT_FLAGS=y
>>   CONFIG_FEATURE_MOUNT_FSTAB=y
>> --
>> 2.17.0
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Khem Raj]

On 5/10/18 11:21 AM, Khem Raj wrote:
> 
> 
> On 5/10/18 6:01 AM, Burton, Ross wrote:
>> Fails to build here:
>>
>>   coreutils/lib.a(mktemp.o): In function `mktemp_main':
>> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105:
>> warning: the use of `mktemp' is dangerous, better use `mkstemp' or
>> `mkdtemp'
>> | util-linux/lib.a(mount.o): In function `xdr_fhstatus':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057:
>> undefined reference to `xdr_u_int'
>> | util-linux/lib.a(mount.o): In function `xdr_fhandle':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052:
>> undefined reference to `xdr_opaque'
>> | util-linux/lib.a(mount.o): In function `xdr_mountstat3':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089:
>> undefined reference to `xdr_enum'
>> | util-linux/lib.a(mount.o): In function `xdr_fhandle3':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071:
>> undefined reference to `xdr_bytes'
>> | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
>> undefined reference to `xdr_int'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
>> undefined reference to `xdr_array'
>> | util-linux/lib.a(mount.o): In function `xdr_dirpath':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066:
>> undefined reference to `xdr_string'
>> | util-linux/lib.a(mount.o): In function `get_mountport':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145:
>> undefined reference to `pmap_getmaps'
>> | util-linux/lib.a(mount.o): In function `nfsmount':
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662:
>> undefined reference to `clnttcp_create'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677:
>> undefined reference to `authunix_create_default'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652:
>> undefined reference to `clntudp_create'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672:
>> undefined reference to `clnt_spcreateerror'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702:
>> undefined reference to `clnt_sperror'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707:
>> undefined reference to `clnt_sperror'
>> | 
>> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788:
>> undefined reference to `pmap_getport'
>>
> 
> We need to specify
> 
> CONFIG_EXTRA_LDLIBS="tirpc"
> 
> along with
> 
> CONFIG_FEATURE_MOUNT_NFS=y
> 
> secondly in v2 please delete
> 
> # CONFIG_FEATURE_MOUNT_NFS is not set
> 
> from meta/recipes-core/busybox/busybox/musl.cfg as well
> 

On second thought, this probably should be enabled using a config 
fragment, since its not gonna link in another library it may not be 
common case to justify for a default config.

>> Ross
>>
>> On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> * We dropped in-tree obsoleted rpc from glibc and now busybox builds
>>>    which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with:
>>>    | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file 
>>> or directory
>>>    |  # include <rpc/rpc.h>
>>>    |            ^~~~~~~~~~~
>>>    | compilation terminated.
>>>    | make[1]: *** [util-linux/mount.o] Error 1
>>>
>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>> ---
>>>   meta/recipes-core/busybox/busybox.inc       | 6 +++---
>>>   meta/recipes-core/busybox/busybox/defconfig | 2 +-
>>>   2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/meta/recipes-core/busybox/busybox.inc 
>>> b/meta/recipes-core/busybox/busybox.inc
>>> index d1675c37aa..2db19ed317 100644
>>> --- a/meta/recipes-core/busybox/busybox.inc
>>> +++ b/meta/recipes-core/busybox/busybox.inc
>>> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many 
>>> common UNIX utilities into
>>>   HOMEPAGE = "http://www.busybox.net"
>>>   BUGTRACKER = "https://bugs.busybox.net/"
>>>
>>> -DEPENDS += "kern-tools-native"
>>> +DEPENDS += "kern-tools-native libtirpc"
>>>
>>>   # bzip2 applet in busybox is based on lightly-modified bzip2 source
>>>   # the GPL is version 2 only
>>> @@ -15,8 +15,8 @@ SECTION = "base"
>>>   # Whether to split the suid apps into a seperate binary
>>>   BUSYBOX_SPLIT_SUID ?= "1"
>>>
>>> -export EXTRA_CFLAGS = "${CFLAGS}"
>>> -export EXTRA_LDFLAGS = "${LDFLAGS}"
>>> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc"
>>> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc"
>>>
>>>   EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
>>> CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' 
>>> HOSTCPP='${BUILD_CPP}'"
>>>
>>> diff --git a/meta/recipes-core/busybox/busybox/defconfig 
>>> b/meta/recipes-core/busybox/busybox/defconfig
>>> index fbb5fd852c..816555fc21 100644
>>> --- a/meta/recipes-core/busybox/busybox/defconfig
>>> +++ b/meta/recipes-core/busybox/busybox/defconfig
>>> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y
>>>   # CONFIG_FEATURE_MOUNT_VERBOSE is not set
>>>   # CONFIG_FEATURE_MOUNT_HELPERS is not set
>>>   # CONFIG_FEATURE_MOUNT_LABEL is not set
>>> -# CONFIG_FEATURE_MOUNT_NFS is not set
>>> +CONFIG_FEATURE_MOUNT_NFS=y
>>>   # CONFIG_FEATURE_MOUNT_CIFS is not set
>>>   CONFIG_FEATURE_MOUNT_FLAGS=y
>>>   CONFIG_FEATURE_MOUNT_FSTAB=y
>>> -- 
>>> 2.17.0
>>>
>>> -- 
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 6634 bytes --]

On Thu, May 10, 2018 at 11:24:02AM -0700, Khem Raj wrote:
> 
> 
> On 5/10/18 11:21 AM, Khem Raj wrote:
> > 
> > 
> > On 5/10/18 6:01 AM, Burton, Ross wrote:
> >> Fails to build here:
> >>
> >>   coreutils/lib.a(mktemp.o): In function `mktemp_main':
> >> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105:
> >> warning: the use of `mktemp' is dangerous, better use `mkstemp' or
> >> `mkdtemp'
> >> | util-linux/lib.a(mount.o): In function `xdr_fhstatus':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057:
> >> undefined reference to `xdr_u_int'
> >> | util-linux/lib.a(mount.o): In function `xdr_fhandle':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052:
> >> undefined reference to `xdr_opaque'
> >> | util-linux/lib.a(mount.o): In function `xdr_mountstat3':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089:
> >> undefined reference to `xdr_enum'
> >> | util-linux/lib.a(mount.o): In function `xdr_fhandle3':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071:
> >> undefined reference to `xdr_bytes'
> >> | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
> >> undefined reference to `xdr_int'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080:
> >> undefined reference to `xdr_array'
> >> | util-linux/lib.a(mount.o): In function `xdr_dirpath':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066:
> >> undefined reference to `xdr_string'
> >> | util-linux/lib.a(mount.o): In function `get_mountport':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145:
> >> undefined reference to `pmap_getmaps'
> >> | util-linux/lib.a(mount.o): In function `nfsmount':
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662:
> >> undefined reference to `clnttcp_create'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677:
> >> undefined reference to `authunix_create_default'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652:
> >> undefined reference to `clntudp_create'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672:
> >> undefined reference to `clnt_spcreateerror'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702:
> >> undefined reference to `clnt_sperror'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707:
> >> undefined reference to `clnt_sperror'
> >> | 
> >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788:
> >> undefined reference to `pmap_getport'
> >>
> > 
> > We need to specify
> > 
> > CONFIG_EXTRA_LDLIBS="tirpc"
> > 
> > along with
> > 
> > CONFIG_FEATURE_MOUNT_NFS=y
> > 
> > secondly in v2 please delete
> > 
> > # CONFIG_FEATURE_MOUNT_NFS is not set
> > 
> > from meta/recipes-core/busybox/busybox/musl.cfg as well
> > 
> 
> On second thought, this probably should be enabled using a config 
> fragment, since its not gonna link in another library it may not be 
> common case to justify for a default config.

That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to
reproduce the issue.

If there isn't interest to enable this by default, I'm fine with keeping this
locally (to enable it only with our defconfig changes which enable it).

> >> Ross
> >>
> >> On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> >>> * We dropped in-tree obsoleted rpc from glibc and now busybox builds
> >>>    which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with:
> >>>    | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file 
> >>> or directory
> >>>    |  # include <rpc/rpc.h>
> >>>    |            ^~~~~~~~~~~
> >>>    | compilation terminated.
> >>>    | make[1]: *** [util-linux/mount.o] Error 1
> >>>
> >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>> ---
> >>>   meta/recipes-core/busybox/busybox.inc       | 6 +++---
> >>>   meta/recipes-core/busybox/busybox/defconfig | 2 +-
> >>>   2 files changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-core/busybox/busybox.inc 
> >>> b/meta/recipes-core/busybox/busybox.inc
> >>> index d1675c37aa..2db19ed317 100644
> >>> --- a/meta/recipes-core/busybox/busybox.inc
> >>> +++ b/meta/recipes-core/busybox/busybox.inc
> >>> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many 
> >>> common UNIX utilities into
> >>>   HOMEPAGE = "http://www.busybox.net"
> >>>   BUGTRACKER = "https://bugs.busybox.net/"
> >>>
> >>> -DEPENDS += "kern-tools-native"
> >>> +DEPENDS += "kern-tools-native libtirpc"
> >>>
> >>>   # bzip2 applet in busybox is based on lightly-modified bzip2 source
> >>>   # the GPL is version 2 only
> >>> @@ -15,8 +15,8 @@ SECTION = "base"
> >>>   # Whether to split the suid apps into a seperate binary
> >>>   BUSYBOX_SPLIT_SUID ?= "1"
> >>>
> >>> -export EXTRA_CFLAGS = "${CFLAGS}"
> >>> -export EXTRA_LDFLAGS = "${LDFLAGS}"
> >>> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc"
> >>> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc"
> >>>
> >>>   EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
> >>> CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' 
> >>> HOSTCPP='${BUILD_CPP}'"
> >>>
> >>> diff --git a/meta/recipes-core/busybox/busybox/defconfig 
> >>> b/meta/recipes-core/busybox/busybox/defconfig
> >>> index fbb5fd852c..816555fc21 100644
> >>> --- a/meta/recipes-core/busybox/busybox/defconfig
> >>> +++ b/meta/recipes-core/busybox/busybox/defconfig
> >>> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y
> >>>   # CONFIG_FEATURE_MOUNT_VERBOSE is not set
> >>>   # CONFIG_FEATURE_MOUNT_HELPERS is not set
> >>>   # CONFIG_FEATURE_MOUNT_LABEL is not set
> >>> -# CONFIG_FEATURE_MOUNT_NFS is not set
> >>> +CONFIG_FEATURE_MOUNT_NFS=y
> >>>   # CONFIG_FEATURE_MOUNT_CIFS is not set
> >>>   CONFIG_FEATURE_MOUNT_FLAGS=y
> >>>   CONFIG_FEATURE_MOUNT_FSTAB=y
> >>> -- 
> >>> 2.17.0
> >>>
> >>> -- 
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Khem Raj]

On 5/10/18 12:16 PM, Martin Jansa wrote:
>> On second thought, this probably should be enabled using a config
>> fragment, since its not gonna link in another library it may not be
>> common case to justify for a default config.
> That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to
> reproduce the issue.
> 
> If there isn't interest to enable this by default, I'm fine with keeping this
> locally (to enable it only with our defconfig changes which enable it).
> 

I think keeping it as a nfsmount.cfg which then can be applied via a 
bbappend could be a good option. May be adding a PACKAGECONFIG to 
control the -I flag and libtirpc dependency would be nice too

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Andre McCurdy]

 On Thu, May 10, 2018 at 12:26 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On 5/10/18 12:16 PM, Martin Jansa wrote:
>>>
>>> On second thought, this probably should be enabled using a config
>>> fragment, since its not gonna link in another library it may not be
>>> common case to justify for a default config.
>>
>> That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to
>> reproduce the issue.
>>
>> If there isn't interest to enable this by default, I'm fine with keeping
>> this
>> locally (to enable it only with our defconfig changes which enable it).
>
> I think keeping it as a nfsmount.cfg which then can be applied via a
> bbappend could be a good option. May be adding a PACKAGECONFIG to control
> the -I flag and libtirpc dependency would be nice too

According to the busybox config help, CONFIG_FEATURE_MOUNT_NFS is only
required for kernel versions before 2.6.23. Do we officially support
kernels that old in oe-core? Or should this be in a .bbappend etc in
separate layer?

//config:config FEATURE_MOUNT_NFS
//config:    bool "Support mounting NFS file systems on Linux < 2.6.23"
//config:    default n
//config:    depends on MOUNT
//config:    select FEATURE_SYSLOG
//config:    help
//config:    Enable mounting of NFS file systems on Linux kernels prior
//config:    to version 2.6.23. Note that in this case mounting of NFS
//config:    over IPv6 will not be possible.
//config:
//config:    Note that this option links in RPC support from libc,
//config:    which is rather large (~10 kbytes on uclibc).

Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

[Martin Jansa]

[-- Attachment #1.1: Type: text/plain, Size: 1929 bytes --]

On Wed, May 30, 2018 at 10:39:16AM -0700, Andre McCurdy wrote:
>  On Thu, May 10, 2018 at 12:26 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > On 5/10/18 12:16 PM, Martin Jansa wrote:
> >>>
> >>> On second thought, this probably should be enabled using a config
> >>> fragment, since its not gonna link in another library it may not be
> >>> common case to justify for a default config.
> >>
> >> That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to
> >> reproduce the issue.
> >>
> >> If there isn't interest to enable this by default, I'm fine with keeping
> >> this
> >> locally (to enable it only with our defconfig changes which enable it).
> >
> > I think keeping it as a nfsmount.cfg which then can be applied via a
> > bbappend could be a good option. May be adding a PACKAGECONFIG to control
> > the -I flag and libtirpc dependency would be nice too
> 
> According to the busybox config help, CONFIG_FEATURE_MOUNT_NFS is only
> required for kernel versions before 2.6.23. Do we officially support
> kernels that old in oe-core? Or should this be in a .bbappend etc in
> separate layer?

OK, I agree that this should be kept in separate layer. If anyone needs
it, the working version (with tirpc added in CONFIG_EXTRA_LDLIBS) is
attached.

> //config:config FEATURE_MOUNT_NFS
> //config:    bool "Support mounting NFS file systems on Linux < 2.6.23"
> //config:    default n
> //config:    depends on MOUNT
> //config:    select FEATURE_SYSLOG
> //config:    help
> //config:    Enable mounting of NFS file systems on Linux kernels prior
> //config:    to version 2.6.23. Note that in this case mounting of NFS
> //config:    over IPv6 will not be possible.
> //config:
> //config:    Note that this option links in RPC support from libc,
> //config:    which is rather large (~10 kbytes on uclibc).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #1.2: 0001-busybox-Enable-FEATURE_MOUNT_NFS-and-use-libtirpc.patch --]
[-- Type: text/x-diff, Size: 2680 bytes --]

From 3316407c73058173bcfa1b9fabcad4592d23cbfc Mon Sep 17 00:00:00 2001
From: Martin Jansa <Martin.Jansa@gmail.com>
Date: Thu, 10 May 2018 12:08:58 +0000
Subject: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc

* We dropped in-tree obsoleted rpc from glibc and now busybox builds
  which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with:
  | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
  |  # include <rpc/rpc.h>
  |            ^~~~~~~~~~~
  | compilation terminated.
  | make[1]: *** [util-linux/mount.o] Error 1

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/recipes-core/busybox/busybox.inc       | 6 +++---
 meta/recipes-core/busybox/busybox/defconfig | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index d1675c37aa..2db19ed317 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into
 HOMEPAGE = "http://www.busybox.net"
 BUGTRACKER = "https://bugs.busybox.net/"
 
-DEPENDS += "kern-tools-native"
+DEPENDS += "kern-tools-native libtirpc"
 
 # bzip2 applet in busybox is based on lightly-modified bzip2 source
 # the GPL is version 2 only
@@ -15,8 +15,8 @@ SECTION = "base"
 # Whether to split the suid apps into a seperate binary
 BUSYBOX_SPLIT_SUID ?= "1"
 
-export EXTRA_CFLAGS = "${CFLAGS}"
-export EXTRA_LDFLAGS = "${LDFLAGS}"
+export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc"
+export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc"
 
 EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'"
 
diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig
index fbb5fd852c..2e920277b7 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -51,7 +51,7 @@ CONFIG_CROSS_COMPILER_PREFIX=""
 CONFIG_SYSROOT=""
 CONFIG_EXTRA_CFLAGS=""
 CONFIG_EXTRA_LDFLAGS=""
-CONFIG_EXTRA_LDLIBS=""
+CONFIG_EXTRA_LDLIBS="tirpc"
 
 #
 # Installation Options ("make install" behavior)
@@ -638,7 +638,7 @@ CONFIG_MOUNT=y
 # CONFIG_FEATURE_MOUNT_VERBOSE is not set
 # CONFIG_FEATURE_MOUNT_HELPERS is not set
 # CONFIG_FEATURE_MOUNT_LABEL is not set
-# CONFIG_FEATURE_MOUNT_NFS is not set
+CONFIG_FEATURE_MOUNT_NFS=y
 # CONFIG_FEATURE_MOUNT_CIFS is not set
 CONFIG_FEATURE_MOUNT_FLAGS=y
 CONFIG_FEATURE_MOUNT_FSTAB=y
-- 
2.17.1


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

Hi Martin

Thanks for testing and reporting back

On 5/9/18 2:38 AM, Martin Jansa wrote:
> My initial tests show couple issues, but usually caused by other changes 
> in that branch, not the gcc-8 itself.
> 
> 1) strace-4.22 from 
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> fails to build with ptest enabled (it builds with 4.20 version if I 
> revert this change)
> ../../strace-4.22/tests/inject-nf.c: In function 'main':
> ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in 
> asm here
>   }
>   ^

are you targeting thumb1 ? how can I reproduce it ?

> Makefile:6313: recipe for target 'inject-nf.o' failed
> make: *** [inject-nf.o] Error 1
> make: Leaving directory 'strace/4.22-r0/build/tests'
> 
> 2) glibc with obsolete rpc disabled from: 
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
> causes busybox's mount applet to fail building:
> util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
>   # include <rpc/rpc.h>
>             ^~~~~~~~~~~
> compilation terminated.
> make[1]: *** [util-linux/mount.o] Error 1
> make: *** [util-linux] Error 2

I think you sent a patch already for this so discussion for fix are on 
going.

> 
> 3) grub and grub-efi fails to build with gcc8:
> In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
> ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
>   } GRUB_PACKED;
>   ^
> In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
> ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
>   } GRUB_PACKED;
>   ^
> ..
> ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct 
> grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
>   } GRUB_PACKED;
>   ^
> 

I think we need to align end of these structs here, can you try
https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch

> 4) iotivity fails to build with gcc8:
> service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: 
> In lambda function:
> service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: 
> error: 'value' is not captured
>                   ocRep[KEY] = value;
>                                ^~~~~
> 

this needs more investigation. May be move
https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160

just above
https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165

> 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> this, it build OK with sumo since the -std=gnu99 addition.
> ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> before the last format character [-Werror=format-truncation=]
>               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
>               ^~~
> 

something new, I will look into reproducing this.

> 6) couple internal components which usually fail to build with gcc8, 
> because of more strict warnings + Werror.

OK, feel free to send out question if you get stuck

> 
> I didn't get very far in testing, because our old kernel fails to build 
> with gcc8 and there are some other issues caused by other master 
> changes. But it doesn't look too bad (in my small test, lets see what 
> bitbake world will show), thanks a lot for new gcc.
> 

yes, older kernel needs fixes, especially to disable new warnings.
the mips/ppc fixes that I put out there might be helpful to cook up 
fixes for older kernels if running into same issues.

> Cheers,
> 
> 
> 
> 
> 
> On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com 
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     Hi All
> 
>     As you might have noticed that gcc 8.1 was released this week, I am
>     calling out for some testing help on testing branch so we can weed out
>     issues you might see in your setups. so if you have your
>     builders idling over weekend, then you know what they can do this
>     weekend :)
> 
>     Highlighted changes are
> 
>     https://gcc.gnu.org/gcc-8/changes.html
>     <https://gcc.gnu.org/gcc-8/changes.html>
> 
>     and porting doc is
> 
>     https://gcc.gnu.org/gcc-8/porting_to.html
>     <https://gcc.gnu.org/gcc-8/porting_to.html>
> 
>     The branch is here
> 
>     http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>     <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8>
> 
>     Its uptodate on top of current master oe-core
> 
>     May fourth be with you !!
> 
>     Cheers!
> 
>     -Khem
>     -- 
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> 
> 

Re: [RFT] GCC 8.1

[Khem Raj]

Hi Martin

Thanks for testing and reporting back

On 5/9/18 2:38 AM, Martin Jansa wrote:
> My initial tests show couple issues, but usually caused by other changes 
> in that branch, not the gcc-8 itself.
> 
> 1) strace-4.22 from 
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> fails to build with ptest enabled (it builds with 4.20 version if I 
> revert this change)
> ../../strace-4.22/tests/inject-nf.c: In function 'main':
> ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in 
> asm here
>   }
>   ^

are you targeting thumb1 ? how can I reproduce it ?

> Makefile:6313: recipe for target 'inject-nf.o' failed
> make: *** [inject-nf.o] Error 1
> make: Leaving directory 'strace/4.22-r0/build/tests'
> 
> 2) glibc with obsolete rpc disabled from: 
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
> causes busybox's mount applet to fail building:
> util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
>   # include <rpc/rpc.h>
>             ^~~~~~~~~~~
> compilation terminated.
> make[1]: *** [util-linux/mount.o] Error 1
> make: *** [util-linux] Error 2

I think you sent a patch already for this so discussion for fix are on 
going.

> 
> 3) grub and grub-efi fails to build with gcc8:
> In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
> ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
>   } GRUB_PACKED;
>   ^
> In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
> ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
>   } GRUB_PACKED;
>   ^
> ..
> ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct 
> grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
>   } GRUB_PACKED;
>   ^
> 

I think we need to align end of these structs here, can you try
https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch

> 4) iotivity fails to build with gcc8:
> service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: 
> In lambda function:
> service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: 
> error: 'value' is not captured
>                   ocRep[KEY] = value;
>                                ^~~~~
> 

this needs more investigation. May be move
https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160

just above
https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165

> 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> this, it build OK with sumo since the -std=gnu99 addition.
> ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> before the last format character [-Werror=format-truncation=]
>               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
>               ^~~
> 

something new, I will look into reproducing this.

> 6) couple internal components which usually fail to build with gcc8, 
> because of more strict warnings + Werror.

OK, feel free to send out question if you get stuck

> 
> I didn't get very far in testing, because our old kernel fails to build 
> with gcc8 and there are some other issues caused by other master 
> changes. But it doesn't look too bad (in my small test, lets see what 
> bitbake world will show), thanks a lot for new gcc.
> 

yes, older kernel needs fixes, especially to disable new warnings.
the mips/ppc fixes that I put out there might be helpful to cook up 
fixes for older kernels if running into same issues.

> Cheers,
> 
> 
> 
> 
> 
> On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com 
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     Hi All
> 
>     As you might have noticed that gcc 8.1 was released this week, I am
>     calling out for some testing help on testing branch so we can weed out
>     issues you might see in your setups. so if you have your
>     builders idling over weekend, then you know what they can do this
>     weekend :)
> 
>     Highlighted changes are
> 
>     https://gcc.gnu.org/gcc-8/changes.html
>     <https://gcc.gnu.org/gcc-8/changes.html>
> 
>     and porting doc is
> 
>     https://gcc.gnu.org/gcc-8/porting_to.html
>     <https://gcc.gnu.org/gcc-8/porting_to.html>
> 
>     The branch is here
> 
>     http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>     <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8>
> 
>     Its uptodate on top of current master oe-core
> 
>     May fourth be with you !!
> 
>     Cheers!
> 
>     -Khem
>     -- 
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> 
> 

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 11927 bytes --]

On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> Hi Martin
> 
> Thanks for testing and reporting back
> 
> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > My initial tests show couple issues, but usually caused by other changes 
> > in that branch, not the gcc-8 itself.
> > 
> > 1) strace-4.22 from 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > fails to build with ptest enabled (it builds with 4.20 version if I 
> > revert this change)
> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in 
> > asm here
> >   }
> >   ^
> 
> are you targeting thumb1 ? how can I reproduce it ?

I'm trying to find out what's different in the builds where it was
failing, will provide more info later.

> > Makefile:6313: recipe for target 'inject-nf.o' failed
> > make: *** [inject-nf.o] Error 1
> > make: Leaving directory 'strace/4.22-r0/build/tests'
> > 
> > 2) glibc with obsolete rpc disabled from: 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
> > causes busybox's mount applet to fail building:
> > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
> >   # include <rpc/rpc.h>
> >             ^~~~~~~~~~~
> > compilation terminated.
> > make[1]: *** [util-linux/mount.o] Error 1
> > make: *** [util-linux] Error 2
> 
> I think you sent a patch already for this so discussion for fix are on 
> going.
> 
> > 
> > 3) grub and grub-efi fails to build with gcc8:
> > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > ..
> > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct 
> > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > 
> 
> I think we need to align end of these structs here, can you try
> https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch

I've sent fix as well:
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150587.html
it's in master-next already.

> > 4) iotivity fails to build with gcc8:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: 
> > In lambda function:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: 
> > error: 'value' is not captured
> >                   ocRep[KEY] = value;
> >                                ^~~~~
> > 
> 
> this needs more investigation. May be move
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160
> 
> just above
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165

There are more issues in iotivity:
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+
+service/resource-encapsulation/unittests/ResourceClientTest.cpp:243:67: error: 'VALUE' is not captured
+extlibs/hippomocks/hippomocks/HippoMocks/hippomocks.h:1609:15: error: void value not ignored as it ought to be

e.g. rapidjson one is tracked upstream:
https://github.com/Tencent/rapidjson/issues/1205

for other issues I have a work around, but not good enough to submit for meta-oic.

> 
> > 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> > this, it build OK with sumo since the -std=gnu99 addition.
> > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> > before the last format character [-Werror=format-truncation=]
> >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
> >               ^~~
> > 
> 
> something new, I will look into reproducing this.
> 
> > 6) couple internal components which usually fail to build with gcc8, 
> > because of more strict warnings + Werror.
> 
> OK, feel free to send out question if you get stuck
> 
> > 
> > I didn't get very far in testing, because our old kernel fails to build 
> > with gcc8 and there are some other issues caused by other master 
> > changes. But it doesn't look too bad (in my small test, lets see what 
> > bitbake world will show), thanks a lot for new gcc.
> > 
> 
> yes, older kernel needs fixes, especially to disable new warnings.
> the mips/ppc fixes that I put out there might be helpful to cook up 
> fixes for older kernels if running into same issues.

In this case it fails with Error: .err encountered for many drivers. It's not the same case as in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html
nor arm version of this change, both are already applied in our
4.4.3 based kernel.

I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't
fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more.

> > Cheers,
> > 
> > 
> > 
> > 
> > 
> > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com 
> > <mailto:raj.khem@gmail.com>> wrote:
> > 
> >     Hi All
> > 
> >     As you might have noticed that gcc 8.1 was released this week, I am
> >     calling out for some testing help on testing branch so we can weed out
> >     issues you might see in your setups. so if you have your
> >     builders idling over weekend, then you know what they can do this
> >     weekend :)
> > 
> >     Highlighted changes are
> > 
> >     https://gcc.gnu.org/gcc-8/changes.html
> >     <https://gcc.gnu.org/gcc-8/changes.html>
> > 
> >     and porting doc is
> > 
> >     https://gcc.gnu.org/gcc-8/porting_to.html
> >     <https://gcc.gnu.org/gcc-8/porting_to.html>
> > 
> >     The branch is here
> > 
> >     http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
> >     <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8>
> > 
> >     Its uptodate on top of current master oe-core
> > 
> >     May fourth be with you !!
> > 
> >     Cheers!
> > 
> >     -Khem
> >     -- 
> >     _______________________________________________
> >     Openembedded-core mailing list
> >     Openembedded-core@lists.openembedded.org
> >     <mailto:Openembedded-core@lists.openembedded.org>
> >     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> > 
> > 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 11927 bytes --]

On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> Hi Martin
> 
> Thanks for testing and reporting back
> 
> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > My initial tests show couple issues, but usually caused by other changes 
> > in that branch, not the gcc-8 itself.
> > 
> > 1) strace-4.22 from 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > fails to build with ptest enabled (it builds with 4.20 version if I 
> > revert this change)
> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in 
> > asm here
> >   }
> >   ^
> 
> are you targeting thumb1 ? how can I reproduce it ?

I'm trying to find out what's different in the builds where it was
failing, will provide more info later.

> > Makefile:6313: recipe for target 'inject-nf.o' failed
> > make: *** [inject-nf.o] Error 1
> > make: Leaving directory 'strace/4.22-r0/build/tests'
> > 
> > 2) glibc with obsolete rpc disabled from: 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
> > causes busybox's mount applet to fail building:
> > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
> >   # include <rpc/rpc.h>
> >             ^~~~~~~~~~~
> > compilation terminated.
> > make[1]: *** [util-linux/mount.o] Error 1
> > make: *** [util-linux] Error 2
> 
> I think you sent a patch already for this so discussion for fix are on 
> going.
> 
> > 
> > 3) grub and grub-efi fails to build with gcc8:
> > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > ..
> > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct 
> > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > 
> 
> I think we need to align end of these structs here, can you try
> https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch

I've sent fix as well:
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150587.html
it's in master-next already.

> > 4) iotivity fails to build with gcc8:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: 
> > In lambda function:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: 
> > error: 'value' is not captured
> >                   ocRep[KEY] = value;
> >                                ^~~~~
> > 
> 
> this needs more investigation. May be move
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160
> 
> just above
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165

There are more issues in iotivity:
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+
+service/resource-encapsulation/unittests/ResourceClientTest.cpp:243:67: error: 'VALUE' is not captured
+extlibs/hippomocks/hippomocks/HippoMocks/hippomocks.h:1609:15: error: void value not ignored as it ought to be

e.g. rapidjson one is tracked upstream:
https://github.com/Tencent/rapidjson/issues/1205

for other issues I have a work around, but not good enough to submit for meta-oic.

> 
> > 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> > this, it build OK with sumo since the -std=gnu99 addition.
> > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> > before the last format character [-Werror=format-truncation=]
> >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
> >               ^~~
> > 
> 
> something new, I will look into reproducing this.
> 
> > 6) couple internal components which usually fail to build with gcc8, 
> > because of more strict warnings + Werror.
> 
> OK, feel free to send out question if you get stuck
> 
> > 
> > I didn't get very far in testing, because our old kernel fails to build 
> > with gcc8 and there are some other issues caused by other master 
> > changes. But it doesn't look too bad (in my small test, lets see what 
> > bitbake world will show), thanks a lot for new gcc.
> > 
> 
> yes, older kernel needs fixes, especially to disable new warnings.
> the mips/ppc fixes that I put out there might be helpful to cook up 
> fixes for older kernels if running into same issues.

In this case it fails with Error: .err encountered for many drivers. It's not the same case as in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html
nor arm version of this change, both are already applied in our
4.4.3 based kernel.

I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't
fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more.

> > Cheers,
> > 
> > 
> > 
> > 
> > 
> > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com 
> > <mailto:raj.khem@gmail.com>> wrote:
> > 
> >     Hi All
> > 
> >     As you might have noticed that gcc 8.1 was released this week, I am
> >     calling out for some testing help on testing branch so we can weed out
> >     issues you might see in your setups. so if you have your
> >     builders idling over weekend, then you know what they can do this
> >     weekend :)
> > 
> >     Highlighted changes are
> > 
> >     https://gcc.gnu.org/gcc-8/changes.html
> >     <https://gcc.gnu.org/gcc-8/changes.html>
> > 
> >     and porting doc is
> > 
> >     https://gcc.gnu.org/gcc-8/porting_to.html
> >     <https://gcc.gnu.org/gcc-8/porting_to.html>
> > 
> >     The branch is here
> > 
> >     http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
> >     <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8>
> > 
> >     Its uptodate on top of current master oe-core
> > 
> >     May fourth be with you !!
> > 
> >     Cheers!
> > 
> >     -Khem
> >     -- 
> >     _______________________________________________
> >     Openembedded-core mailing list
> >     Openembedded-core@lists.openembedded.org
> >     <mailto:Openembedded-core@lists.openembedded.org>
> >     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> > 
> > 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> Hi Martin
>>
>> Thanks for testing and reporting back
>>
>> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > My initial tests show couple issues, but usually caused by other changes
>> > in that branch, not the gcc-8 itself.
>> >
>> > 1) strace-4.22 from
>> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > revert this change)
>> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > asm here
>> >   }
>> >   ^
>>
>> are you targeting thumb1 ? how can I reproduce it ?
>
> I'm trying to find out what's different in the builds where it was
> failing, will provide more info later.

This is probably due to making an inline syscall from Thumb (doesn't a
matter Thumb1 or Thumb2) with frame pointers enabled.

Does adding -fomit-frame-pointer to CFLAGS fix it?

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> Hi Martin
>>
>> Thanks for testing and reporting back
>>
>> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > My initial tests show couple issues, but usually caused by other changes
>> > in that branch, not the gcc-8 itself.
>> >
>> > 1) strace-4.22 from
>> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > revert this change)
>> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > asm here
>> >   }
>> >   ^
>>
>> are you targeting thumb1 ? how can I reproduce it ?
>
> I'm trying to find out what's different in the builds where it was
> failing, will provide more info later.

This is probably due to making an inline syscall from Thumb (doesn't a
matter Thumb1 or Thumb2) with frame pointers enabled.

Does adding -fomit-frame-pointer to CFLAGS fix it?

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> Hi Martin
> >>
> >> Thanks for testing and reporting back
> >>
> >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > My initial tests show couple issues, but usually caused by other changes
> >> > in that branch, not the gcc-8 itself.
> >> >
> >> > 1) strace-4.22 from
> >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > fails to build with ptest enabled (it builds with 4.20 version if I
> >> > revert this change)
> >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
> >> > asm here
> >> >   }
> >> >   ^
> >>
> >> are you targeting thumb1 ? how can I reproduce it ?
> >
> > I'm trying to find out what's different in the builds where it was
> > failing, will provide more info later.
> 
> This is probably due to making an inline syscall from Thumb (doesn't a
> matter Thumb1 or Thumb2) with frame pointers enabled.
> 
> Does adding -fomit-frame-pointer to CFLAGS fix it?

It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
already -fno-omit-frame-pointer in the default command line for it,
adding -fomit-frame-pointer at the end fixes it:

docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer

This might come from:
meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
because in this build I had DEBUG_BUILD enabled.

Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.

Thanks for pointers.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> Hi Martin
> >>
> >> Thanks for testing and reporting back
> >>
> >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > My initial tests show couple issues, but usually caused by other changes
> >> > in that branch, not the gcc-8 itself.
> >> >
> >> > 1) strace-4.22 from
> >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > fails to build with ptest enabled (it builds with 4.20 version if I
> >> > revert this change)
> >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
> >> > asm here
> >> >   }
> >> >   ^
> >>
> >> are you targeting thumb1 ? how can I reproduce it ?
> >
> > I'm trying to find out what's different in the builds where it was
> > failing, will provide more info later.
> 
> This is probably due to making an inline syscall from Thumb (doesn't a
> matter Thumb1 or Thumb2) with frame pointers enabled.
> 
> Does adding -fomit-frame-pointer to CFLAGS fix it?

It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
already -fno-omit-frame-pointer in the default command line for it,
adding -fomit-frame-pointer at the end fixes it:

docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer

This might come from:
meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
because in this build I had DEBUG_BUILD enabled.

Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.

Thanks for pointers.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]

On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> > >> Hi Martin
> > >>
> > >> Thanks for testing and reporting back
> > >>
> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > >> > My initial tests show couple issues, but usually caused by other changes
> > >> > in that branch, not the gcc-8 itself.
> > >> >
> > >> > 1) strace-4.22 from
> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
> > >> > revert this change)
> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
> > >> > asm here
> > >> >   }
> > >> >   ^
> > >>
> > >> are you targeting thumb1 ? how can I reproduce it ?
> > >
> > > I'm trying to find out what's different in the builds where it was
> > > failing, will provide more info later.
> > 
> > This is probably due to making an inline syscall from Thumb (doesn't a
> > matter Thumb1 or Thumb2) with frame pointers enabled.
> > 
> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> 
> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> already -fno-omit-frame-pointer in the default command line for it,
> adding -fomit-frame-pointer at the end fixes it:
> 
> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer
> 
> This might come from:
> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
> because in this build I had DEBUG_BUILD enabled.
> 
> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.

4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
4.22:

https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1

What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
when ptest is in DISTRO_FEATURES acceptable solution?

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]

On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> > >> Hi Martin
> > >>
> > >> Thanks for testing and reporting back
> > >>
> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > >> > My initial tests show couple issues, but usually caused by other changes
> > >> > in that branch, not the gcc-8 itself.
> > >> >
> > >> > 1) strace-4.22 from
> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
> > >> > revert this change)
> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
> > >> > asm here
> > >> >   }
> > >> >   ^
> > >>
> > >> are you targeting thumb1 ? how can I reproduce it ?
> > >
> > > I'm trying to find out what's different in the builds where it was
> > > failing, will provide more info later.
> > 
> > This is probably due to making an inline syscall from Thumb (doesn't a
> > matter Thumb1 or Thumb2) with frame pointers enabled.
> > 
> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> 
> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> already -fno-omit-frame-pointer in the default command line for it,
> adding -fomit-frame-pointer at the end fixes it:
> 
> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer
> 
> This might come from:
> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
> because in this build I had DEBUG_BUILD enabled.
> 
> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.

4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
4.22:

https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1

What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
when ptest is in DISTRO_FEATURES acceptable solution?

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> > >> Hi Martin
>> > >>
>> > >> Thanks for testing and reporting back
>> > >>
>> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > >> > My initial tests show couple issues, but usually caused by other changes
>> > >> > in that branch, not the gcc-8 itself.
>> > >> >
>> > >> > 1) strace-4.22 from
>> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > >> > revert this change)
>> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > >> > asm here
>> > >> >   }
>> > >> >   ^
>> > >>
>> > >> are you targeting thumb1 ? how can I reproduce it ?
>> > >
>> > > I'm trying to find out what's different in the builds where it was
>> > > failing, will provide more info later.
>> >
>> > This is probably due to making an inline syscall from Thumb (doesn't a
>> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >
>> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>>
>> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> already -fno-omit-frame-pointer in the default command line for it,
>> adding -fomit-frame-pointer at the end fixes it:
>>
>> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer
>>
>> This might come from:
>> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
>> because in this build I had DEBUG_BUILD enabled.
>>
>> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.
>
> 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> 4.22:
>
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>
> What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> when ptest is in DISTRO_FEATURES acceptable solution?

you might want to _remove operation for -fno-omit-frame-pointer for
SELECTED_OPTIMIZATION variable.

Re: [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> > >> Hi Martin
>> > >>
>> > >> Thanks for testing and reporting back
>> > >>
>> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > >> > My initial tests show couple issues, but usually caused by other changes
>> > >> > in that branch, not the gcc-8 itself.
>> > >> >
>> > >> > 1) strace-4.22 from
>> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > >> > revert this change)
>> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > >> > asm here
>> > >> >   }
>> > >> >   ^
>> > >>
>> > >> are you targeting thumb1 ? how can I reproduce it ?
>> > >
>> > > I'm trying to find out what's different in the builds where it was
>> > > failing, will provide more info later.
>> >
>> > This is probably due to making an inline syscall from Thumb (doesn't a
>> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >
>> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>>
>> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> already -fno-omit-frame-pointer in the default command line for it,
>> adding -fomit-frame-pointer at the end fixes it:
>>
>> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer
>>
>> This might come from:
>> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
>> because in this build I had DEBUG_BUILD enabled.
>>
>> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.
>
> 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> 4.22:
>
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>
> What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> when ptest is in DISTRO_FEATURES acceptable solution?

you might want to _remove operation for -fno-omit-frame-pointer for
SELECTED_OPTIMIZATION variable.

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> > >> Hi Martin
>> > >>
>> > >> Thanks for testing and reporting back
>> > >>
>> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > >> > My initial tests show couple issues, but usually caused by other changes
>> > >> > in that branch, not the gcc-8 itself.
>> > >> >
>> > >> > 1) strace-4.22 from
>> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > >> > revert this change)
>> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > >> > asm here
>> > >> >   }
>> > >> >   ^
>> > >>
>> > >> are you targeting thumb1 ? how can I reproduce it ?
>> > >
>> > > I'm trying to find out what's different in the builds where it was
>> > > failing, will provide more info later.
>> >
>> > This is probably due to making an inline syscall from Thumb (doesn't a
>> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >
>> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>>
>> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> already -fno-omit-frame-pointer in the default command line for it,
>> adding -fomit-frame-pointer at the end fixes it:
>>
>> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer
>>
>> This might come from:
>> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
>> because in this build I had DEBUG_BUILD enabled.
>>
>> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.
>
> 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> 4.22:
>
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>
> What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> when ptest is in DISTRO_FEATURES acceptable solution?

I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
all builds is OK (strace is a debug tool - not something that
generally needs to be debugged and frame pointers aren't essential for
debugging anyway).

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> > >> Hi Martin
>> > >>
>> > >> Thanks for testing and reporting back
>> > >>
>> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > >> > My initial tests show couple issues, but usually caused by other changes
>> > >> > in that branch, not the gcc-8 itself.
>> > >> >
>> > >> > 1) strace-4.22 from
>> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > >> > revert this change)
>> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > >> > asm here
>> > >> >   }
>> > >> >   ^
>> > >>
>> > >> are you targeting thumb1 ? how can I reproduce it ?
>> > >
>> > > I'm trying to find out what's different in the builds where it was
>> > > failing, will provide more info later.
>> >
>> > This is probably due to making an inline syscall from Thumb (doesn't a
>> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >
>> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>>
>> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> already -fno-omit-frame-pointer in the default command line for it,
>> adding -fomit-frame-pointer at the end fixes it:
>>
>> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer
>>
>> This might come from:
>> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
>> because in this build I had DEBUG_BUILD enabled.
>>
>> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now.
>
> 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> 4.22:
>
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>
> What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> when ptest is in DISTRO_FEATURES acceptable solution?

I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
all builds is OK (strace is a debug tool - not something that
generally needs to be debugged and frame pointers aren't essential for
debugging anyway).

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4242 bytes --]

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:

> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <
> martin.jansa@gmail.com> wrote:
> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> > >> Hi Martin
> >> > >>
> >> > >> Thanks for testing and reporting back
> >> > >>
> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > >> > My initial tests show couple issues, but usually caused by other
> changes
> >> > >> > in that branch, not the gcc-8 itself.
> >> > >> >
> >> > >> > 1) strace-4.22 from
> >> > >> >
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> if I
> >> > >> > revert this change)
> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> used in
> >> > >> > asm here
> >> > >> >   }
> >> > >> >   ^
> >> > >>
> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> > >
> >> > > I'm trying to find out what's different in the builds where it was
> >> > > failing, will provide more info later.
> >> >
> >> > This is probably due to making an inline syscall from Thumb (doesn't a
> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >
> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >>
> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> already -fno-omit-frame-pointer in the default command line for it,
> >> adding -fomit-frame-pointer at the end fixes it:
> >>
> >> docker-lge @
> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> -mfloat-abi=hard -mcpu=cortex-a7
> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
> -Wwrite-strings -O -fno-omit-frame-pointer -g
> -feliminate-unused-debug-types
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
> -fomit-frame-pointer
> >>
> >> This might come from:
> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
> ${DEBUG_FLAGS} -pipe"
> >> because in this build I had DEBUG_BUILD enabled.
> >>
> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
> well now.
> >
> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> > 4.22:
> >
> >
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
> >
> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> > when ptest is in DISTRO_FEATURES acceptable solution?
>
> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
> all builds is OK (strace is a debug tool - not something that
> generally needs to be debugged and frame pointers aren't essential for
> debugging anyway).
>

[-- Attachment #2: Type: text/html, Size: 5654 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:

> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <
> martin.jansa@gmail.com> wrote:
> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> > >> Hi Martin
> >> > >>
> >> > >> Thanks for testing and reporting back
> >> > >>
> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > >> > My initial tests show couple issues, but usually caused by other
> changes
> >> > >> > in that branch, not the gcc-8 itself.
> >> > >> >
> >> > >> > 1) strace-4.22 from
> >> > >> >
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> if I
> >> > >> > revert this change)
> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> used in
> >> > >> > asm here
> >> > >> >   }
> >> > >> >   ^
> >> > >>
> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> > >
> >> > > I'm trying to find out what's different in the builds where it was
> >> > > failing, will provide more info later.
> >> >
> >> > This is probably due to making an inline syscall from Thumb (doesn't a
> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >
> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >>
> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> already -fno-omit-frame-pointer in the default command line for it,
> >> adding -fomit-frame-pointer at the end fixes it:
> >>
> >> docker-lge @
> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> -mfloat-abi=hard -mcpu=cortex-a7
> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
> -Wwrite-strings -O -fno-omit-frame-pointer -g
> -feliminate-unused-debug-types
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
> -fomit-frame-pointer
> >>
> >> This might come from:
> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
> ${DEBUG_FLAGS} -pipe"
> >> because in this build I had DEBUG_BUILD enabled.
> >>
> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
> well now.
> >
> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> > 4.22:
> >
> >
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
> >
> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> > when ptest is in DISTRO_FEATURES acceptable solution?
>
> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
> all builds is OK (strace is a debug tool - not something that
> generally needs to be debugged and frame pointers aren't essential for
> debugging anyway).
>

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4242 bytes --]

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:

> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <
> martin.jansa@gmail.com> wrote:
> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> > >> Hi Martin
> >> > >>
> >> > >> Thanks for testing and reporting back
> >> > >>
> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > >> > My initial tests show couple issues, but usually caused by other
> changes
> >> > >> > in that branch, not the gcc-8 itself.
> >> > >> >
> >> > >> > 1) strace-4.22 from
> >> > >> >
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> if I
> >> > >> > revert this change)
> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> used in
> >> > >> > asm here
> >> > >> >   }
> >> > >> >   ^
> >> > >>
> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> > >
> >> > > I'm trying to find out what's different in the builds where it was
> >> > > failing, will provide more info later.
> >> >
> >> > This is probably due to making an inline syscall from Thumb (doesn't a
> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >
> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >>
> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> already -fno-omit-frame-pointer in the default command line for it,
> >> adding -fomit-frame-pointer at the end fixes it:
> >>
> >> docker-lge @
> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> -mfloat-abi=hard -mcpu=cortex-a7
> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
> -Wwrite-strings -O -fno-omit-frame-pointer -g
> -feliminate-unused-debug-types
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
> -fomit-frame-pointer
> >>
> >> This might come from:
> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
> ${DEBUG_FLAGS} -pipe"
> >> because in this build I had DEBUG_BUILD enabled.
> >>
> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
> well now.
> >
> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> > 4.22:
> >
> >
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
> >
> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> > when ptest is in DISTRO_FEATURES acceptable solution?
>
> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
> all builds is OK (strace is a debug tool - not something that
> generally needs to be debugged and frame pointers aren't essential for
> debugging anyway).
>

[-- Attachment #2: Type: text/html, Size: 5654 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> see
> http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Removing -fno-omit-frame-pointer isn't the same as adding
-fomit-frame-pointer. Frame pointers may get enabled depending on the
optimisation level etc (ie not only by -fno-omit-frame-pointer).

> On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
>> wrote:
>> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa
>> >> > <martin.jansa@gmail.com> wrote:
>> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> >> > >> Hi Martin
>> >> > >>
>> >> > >> Thanks for testing and reporting back
>> >> > >>
>> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> >> > >> > My initial tests show couple issues, but usually caused by other
>> >> > >> > changes
>> >> > >> > in that branch, not the gcc-8 itself.
>> >> > >> >
>> >> > >> > 1) strace-4.22 from
>> >> > >> >
>> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
>> >> > >> > if I
>> >> > >> > revert this change)
>> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
>> >> > >> > used in
>> >> > >> > asm here
>> >> > >> >   }
>> >> > >> >   ^
>> >> > >>
>> >> > >> are you targeting thumb1 ? how can I reproduce it ?
>> >> > >
>> >> > > I'm trying to find out what's different in the builds where it was
>> >> > > failing, will provide more info later.
>> >> >
>> >> > This is probably due to making an inline syscall from Thumb (doesn't
>> >> > a
>> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >> >
>> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>> >>
>> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> >> already -fno-omit-frame-pointer in the default command line for it,
>> >> adding -fomit-frame-pointer at the end fixes it:
>> >>
>> >> docker-lge @
>> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
>> >> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
>> >> -mfloat-abi=hard -mcpu=cortex-a7
>> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
>> >> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
>> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
>> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
>> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
>> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
>> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
>> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
>> >> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
>> >> -fomit-frame-pointer
>> >>
>> >> This might come from:
>> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
>> >> ${DEBUG_FLAGS} -pipe"
>> >> because in this build I had DEBUG_BUILD enabled.
>> >>
>> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
>> >> well now.
>> >
>> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
>> > 4.22:
>> >
>> >
>> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>> >
>> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
>> > when ptest is in DISTRO_FEATURES acceptable solution?
>>
>> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
>> all builds is OK (strace is a debug tool - not something that
>> generally needs to be debugged and frame pointers aren't essential for
>> debugging anyway).

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> see
> http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Removing -fno-omit-frame-pointer isn't the same as adding
-fomit-frame-pointer. Frame pointers may get enabled depending on the
optimisation level etc (ie not only by -fno-omit-frame-pointer).

> On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
>> wrote:
>> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa
>> >> > <martin.jansa@gmail.com> wrote:
>> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> >> > >> Hi Martin
>> >> > >>
>> >> > >> Thanks for testing and reporting back
>> >> > >>
>> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> >> > >> > My initial tests show couple issues, but usually caused by other
>> >> > >> > changes
>> >> > >> > in that branch, not the gcc-8 itself.
>> >> > >> >
>> >> > >> > 1) strace-4.22 from
>> >> > >> >
>> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
>> >> > >> > if I
>> >> > >> > revert this change)
>> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
>> >> > >> > used in
>> >> > >> > asm here
>> >> > >> >   }
>> >> > >> >   ^
>> >> > >>
>> >> > >> are you targeting thumb1 ? how can I reproduce it ?
>> >> > >
>> >> > > I'm trying to find out what's different in the builds where it was
>> >> > > failing, will provide more info later.
>> >> >
>> >> > This is probably due to making an inline syscall from Thumb (doesn't
>> >> > a
>> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >> >
>> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>> >>
>> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> >> already -fno-omit-frame-pointer in the default command line for it,
>> >> adding -fomit-frame-pointer at the end fixes it:
>> >>
>> >> docker-lge @
>> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
>> >> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
>> >> -mfloat-abi=hard -mcpu=cortex-a7
>> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
>> >> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
>> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
>> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
>> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
>> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
>> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
>> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
>> >> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
>> >> -fomit-frame-pointer
>> >>
>> >> This might come from:
>> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
>> >> ${DEBUG_FLAGS} -pipe"
>> >> because in this build I had DEBUG_BUILD enabled.
>> >>
>> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
>> >> well now.
>> >
>> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
>> > 4.22:
>> >
>> >
>> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>> >
>> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
>> > when ptest is in DISTRO_FEATURES acceptable solution?
>>
>> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
>> all builds is OK (strace is a debug tool - not something that
>> generally needs to be debugged and frame pointers aren't essential for
>> debugging anyway).

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5185 bytes --]

On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > see
> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
> 
> Removing -fno-omit-frame-pointer isn't the same as adding
> -fomit-frame-pointer. Frame pointers may get enabled depending on the
> optimisation level etc (ie not only by -fno-omit-frame-pointer).

Should I send v2 adding -fomit-frame-pointer instead of removing
-fno-omit-frame-pointer?

The v1 fixes the issue for me with default config + DEBUG_BUILD.

> > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:
> >>
> >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
> >> wrote:
> >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa
> >> >> > <martin.jansa@gmail.com> wrote:
> >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> >> > >> Hi Martin
> >> >> > >>
> >> >> > >> Thanks for testing and reporting back
> >> >> > >>
> >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> >> > >> > My initial tests show couple issues, but usually caused by other
> >> >> > >> > changes
> >> >> > >> > in that branch, not the gcc-8 itself.
> >> >> > >> >
> >> >> > >> > 1) strace-4.22 from
> >> >> > >> >
> >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> >> >> > >> > if I
> >> >> > >> > revert this change)
> >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> >> >> > >> > used in
> >> >> > >> > asm here
> >> >> > >> >   }
> >> >> > >> >   ^
> >> >> > >>
> >> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> >> > >
> >> >> > > I'm trying to find out what's different in the builds where it was
> >> >> > > failing, will provide more info later.
> >> >> >
> >> >> > This is probably due to making an inline syscall from Thumb (doesn't
> >> >> > a
> >> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >> >
> >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >> >>
> >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> >> already -fno-omit-frame-pointer in the default command line for it,
> >> >> adding -fomit-frame-pointer at the end fixes it:
> >> >>
> >> >> docker-lge @
> >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> >> >> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> >> >> -mfloat-abi=hard -mcpu=cortex-a7
> >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> >> >> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
> >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
> >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
> >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
> >> >> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
> >> >> -fomit-frame-pointer
> >> >>
> >> >> This might come from:
> >> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
> >> >> ${DEBUG_FLAGS} -pipe"
> >> >> because in this build I had DEBUG_BUILD enabled.
> >> >>
> >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
> >> >> well now.
> >> >
> >> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> >> > 4.22:
> >> >
> >> >
> >> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
> >> >
> >> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> >> > when ptest is in DISTRO_FEATURES acceptable solution?
> >>
> >> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
> >> all builds is OK (strace is a debug tool - not something that
> >> generally needs to be debugged and frame pointers aren't essential for
> >> debugging anyway).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5185 bytes --]

On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > see
> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
> 
> Removing -fno-omit-frame-pointer isn't the same as adding
> -fomit-frame-pointer. Frame pointers may get enabled depending on the
> optimisation level etc (ie not only by -fno-omit-frame-pointer).

Should I send v2 adding -fomit-frame-pointer instead of removing
-fno-omit-frame-pointer?

The v1 fixes the issue for me with default config + DEBUG_BUILD.

> > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote:
> >>
> >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com>
> >> wrote:
> >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa
> >> >> > <martin.jansa@gmail.com> wrote:
> >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> >> > >> Hi Martin
> >> >> > >>
> >> >> > >> Thanks for testing and reporting back
> >> >> > >>
> >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> >> > >> > My initial tests show couple issues, but usually caused by other
> >> >> > >> > changes
> >> >> > >> > in that branch, not the gcc-8 itself.
> >> >> > >> >
> >> >> > >> > 1) strace-4.22 from
> >> >> > >> >
> >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> >> >> > >> > if I
> >> >> > >> > revert this change)
> >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> >> >> > >> > used in
> >> >> > >> > asm here
> >> >> > >> >   }
> >> >> > >> >   ^
> >> >> > >>
> >> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> >> > >
> >> >> > > I'm trying to find out what's different in the builds where it was
> >> >> > > failing, will provide more info later.
> >> >> >
> >> >> > This is probably due to making an inline syscall from Thumb (doesn't
> >> >> > a
> >> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >> >
> >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >> >>
> >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> >> already -fno-omit-frame-pointer in the default command line for it,
> >> >> adding -fomit-frame-pointer at the end fixes it:
> >> >>
> >> >> docker-lge @
> >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> >> >> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> >> >> -mfloat-abi=hard -mcpu=cortex-a7
> >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> >> >> -DHAVE_CONFIG_H    -I. -I../linux/arm -I../../strace-4.22/linux/arm
> >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
> >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
> >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
> >> >> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
> >> >> -fomit-frame-pointer
> >> >>
> >> >> This might come from:
> >> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
> >> >> ${DEBUG_FLAGS} -pipe"
> >> >> because in this build I had DEBUG_BUILD enabled.
> >> >>
> >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
> >> >> well now.
> >> >
> >> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> >> > 4.22:
> >> >
> >> >
> >> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
> >> >
> >> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> >> > when ptest is in DISTRO_FEATURES acceptable solution?
> >>
> >> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
> >> all builds is OK (strace is a debug tool - not something that
> >> generally needs to be debugged and frame pointers aren't essential for
> >> debugging anyway).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > see
>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>
>> Removing -fno-omit-frame-pointer isn't the same as adding
>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>
> Should I send v2 adding -fomit-frame-pointer instead of removing
> -fno-omit-frame-pointer?
>
> The v1 fixes the issue for me with default config + DEBUG_BUILD.

The v1 patch isn't wrong, it's just incomplete (the problem could come
back if someone changes optimisation level or switches gcc to clang,
etc).

My choice would be a v2 patch which adds -fomit-frame-pointer to
CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
should fix the problem for all optimisation levels etc and avoids
building the main strace binary differently depending on whether or
not ptest is enabled.

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > see
>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>
>> Removing -fno-omit-frame-pointer isn't the same as adding
>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>
> Should I send v2 adding -fomit-frame-pointer instead of removing
> -fno-omit-frame-pointer?
>
> The v1 fixes the issue for me with default config + DEBUG_BUILD.

The v1 patch isn't wrong, it's just incomplete (the problem could come
back if someone changes optimisation level or switches gcc to clang,
etc).

My choice would be a v2 patch which adds -fomit-frame-pointer to
CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
should fix the problem for all optimisation levels etc and avoids
building the main strace binary differently depending on whether or
not ptest is enabled.

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >> > see
> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
> >>
> >> Removing -fno-omit-frame-pointer isn't the same as adding
> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the
> >> optimisation level etc (ie not only by -fno-omit-frame-pointer).
> >
> > Should I send v2 adding -fomit-frame-pointer instead of removing
> > -fno-omit-frame-pointer?
> >
> > The v1 fixes the issue for me with default config + DEBUG_BUILD.
> 
> The v1 patch isn't wrong, it's just incomplete (the problem could come
> back if someone changes optimisation level or switches gcc to clang,
> etc).
> 
> My choice would be a v2 patch which adds -fomit-frame-pointer to
> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
> should fix the problem for all optimisation levels etc and avoids
> building the main strace binary differently depending on whether or
> not ptest is enabled.

Only for thumb? makes me a bit sad that thumb override was dropped by
you in
351443d71eb246a946b41f12b54d57b36fe1574e

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >> > see
> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
> >>
> >> Removing -fno-omit-frame-pointer isn't the same as adding
> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the
> >> optimisation level etc (ie not only by -fno-omit-frame-pointer).
> >
> > Should I send v2 adding -fomit-frame-pointer instead of removing
> > -fno-omit-frame-pointer?
> >
> > The v1 fixes the issue for me with default config + DEBUG_BUILD.
> 
> The v1 patch isn't wrong, it's just incomplete (the problem could come
> back if someone changes optimisation level or switches gcc to clang,
> etc).
> 
> My choice would be a v2 patch which adds -fomit-frame-pointer to
> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
> should fix the problem for all optimisation levels etc and avoids
> building the main strace binary differently depending on whether or
> not ptest is enabled.

Only for thumb? makes me a bit sad that thumb override was dropped by
you in
351443d71eb246a946b41f12b54d57b36fe1574e

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 4:32 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> >> > see
>> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>> >>
>> >> Removing -fno-omit-frame-pointer isn't the same as adding
>> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>> >> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>> >
>> > Should I send v2 adding -fomit-frame-pointer instead of removing
>> > -fno-omit-frame-pointer?
>> >
>> > The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> Only for thumb? makes me a bit sad that thumb override was dropped by
> you in
> 351443d71eb246a946b41f12b54d57b36fe1574e

No need for a thumb over-ride. You can copy and paste from the musl recipe:

CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb',
'-fomit-frame-pointer', '', d)}"

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 4:32 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> >> > see
>> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>> >>
>> >> Removing -fno-omit-frame-pointer isn't the same as adding
>> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>> >> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>> >
>> > Should I send v2 adding -fomit-frame-pointer instead of removing
>> > -fno-omit-frame-pointer?
>> >
>> > The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> Only for thumb? makes me a bit sad that thumb override was dropped by
> you in
> 351443d71eb246a946b41f12b54d57b36fe1574e

No need for a thumb over-ride. You can copy and paste from the musl recipe:

CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb',
'-fomit-frame-pointer', '', d)}"

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> > see
>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>
>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>
>> Should I send v2 adding -fomit-frame-pointer instead of removing
>> -fno-omit-frame-pointer?
>>
>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>
> The v1 patch isn't wrong, it's just incomplete (the problem could come
> back if someone changes optimisation level or switches gcc to clang,
> etc).
>
> My choice would be a v2 patch which adds -fomit-frame-pointer to
> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
> should fix the problem for all optimisation levels etc and avoids
> building the main strace binary differently depending on whether or
> not ptest is enabled.

explicitly adding this option is a poor choice especially for debug
builds where we should
let the -On level decide and not explicitly ask for either
enable/disable frame-pointers
that will also make it compiler proof.

Re: [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> > see
>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>
>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>
>> Should I send v2 adding -fomit-frame-pointer instead of removing
>> -fno-omit-frame-pointer?
>>
>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>
> The v1 patch isn't wrong, it's just incomplete (the problem could come
> back if someone changes optimisation level or switches gcc to clang,
> etc).
>
> My choice would be a v2 patch which adds -fomit-frame-pointer to
> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
> should fix the problem for all optimisation levels etc and avoids
> building the main strace binary differently depending on whether or
> not ptest is enabled.

explicitly adding this option is a poor choice especially for debug
builds where we should
let the -On level decide and not explicitly ask for either
enable/disable frame-pointers
that will also make it compiler proof.

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> > see
>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>
>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>
>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>> -fno-omit-frame-pointer?
>>>
>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> explicitly adding this option is a poor choice especially for debug
> builds where we should
> let the -On level decide and not explicitly ask for either
> enable/disable frame-pointers
> that will also make it compiler proof.

Of course, we should let the compiler decide whenever it's possible to do so.

Unfortunately there are cases like this one where frame pointers clash
with inline assembler and we need to over-rule the compiler's choice.

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> > see
>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>
>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>
>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>> -fno-omit-frame-pointer?
>>>
>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> explicitly adding this option is a poor choice especially for debug
> builds where we should
> let the -On level decide and not explicitly ask for either
> enable/disable frame-pointers
> that will also make it compiler proof.

Of course, we should let the compiler decide whenever it's possible to do so.

Unfortunately there are cases like this one where frame pointers clash
with inline assembler and we need to over-rule the compiler's choice.

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>> > see
>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>
>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>
>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>> -fno-omit-frame-pointer?
>>>>
>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>
>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>> back if someone changes optimisation level or switches gcc to clang,
>>> etc).
>>>
>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>> should fix the problem for all optimisation levels etc and avoids
>>> building the main strace binary differently depending on whether or
>>> not ptest is enabled.
>>
>> explicitly adding this option is a poor choice especially for debug
>> builds where we should
>> let the -On level decide and not explicitly ask for either
>> enable/disable frame-pointers
>> that will also make it compiler proof.
>
> Of course, we should let the compiler decide whenever it's possible to do so.
>
> Unfortunately there are cases like this one where frame pointers clash
> with inline assembler and we need to over-rule the compiler's choice.

Here we are adding -fno-omit-frame-pointer via global opt flags that
is the issue
where we have fallouts from default O options I agree we should teach
this to build
system and help the compiler

Re: [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>> > see
>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>
>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>
>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>> -fno-omit-frame-pointer?
>>>>
>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>
>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>> back if someone changes optimisation level or switches gcc to clang,
>>> etc).
>>>
>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>> should fix the problem for all optimisation levels etc and avoids
>>> building the main strace binary differently depending on whether or
>>> not ptest is enabled.
>>
>> explicitly adding this option is a poor choice especially for debug
>> builds where we should
>> let the -On level decide and not explicitly ask for either
>> enable/disable frame-pointers
>> that will also make it compiler proof.
>
> Of course, we should let the compiler decide whenever it's possible to do so.
>
> Unfortunately there are cases like this one where frame pointers clash
> with inline assembler and we need to over-rule the compiler's choice.

Here we are adding -fno-omit-frame-pointer via global opt flags that
is the issue
where we have fallouts from default O options I agree we should teach
this to build
system and help the compiler

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>> > see
>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>
>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>
>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>> -fno-omit-frame-pointer?
>>>>>
>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>
>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>> back if someone changes optimisation level or switches gcc to clang,
>>>> etc).
>>>>
>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>> should fix the problem for all optimisation levels etc and avoids
>>>> building the main strace binary differently depending on whether or
>>>> not ptest is enabled.
>>>
>>> explicitly adding this option is a poor choice especially for debug
>>> builds where we should
>>> let the -On level decide and not explicitly ask for either
>>> enable/disable frame-pointers
>>> that will also make it compiler proof.
>>
>> Of course, we should let the compiler decide whenever it's possible to do so.
>>
>> Unfortunately there are cases like this one where frame pointers clash
>> with inline assembler and we need to over-rule the compiler's choice.
>
> Here we are adding -fno-omit-frame-pointer via global opt flags that
> is the issue
> where we have fallouts from default O options I agree we should teach
> this to build
> system and help the compiler

Since there's NO situation where enabling frame pointers is going to
work for this code + ARM + Thumb, I don't see the advantage of leaving
anything up to chance. Just explicitly disabling frame pointers is the
safest and cleanest option.

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>> > see
>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>
>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>
>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>> -fno-omit-frame-pointer?
>>>>>
>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>
>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>> back if someone changes optimisation level or switches gcc to clang,
>>>> etc).
>>>>
>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>> should fix the problem for all optimisation levels etc and avoids
>>>> building the main strace binary differently depending on whether or
>>>> not ptest is enabled.
>>>
>>> explicitly adding this option is a poor choice especially for debug
>>> builds where we should
>>> let the -On level decide and not explicitly ask for either
>>> enable/disable frame-pointers
>>> that will also make it compiler proof.
>>
>> Of course, we should let the compiler decide whenever it's possible to do so.
>>
>> Unfortunately there are cases like this one where frame pointers clash
>> with inline assembler and we need to over-rule the compiler's choice.
>
> Here we are adding -fno-omit-frame-pointer via global opt flags that
> is the issue
> where we have fallouts from default O options I agree we should teach
> this to build
> system and help the compiler

Since there's NO situation where enabling frame pointers is going to
work for this code + ARM + Thumb, I don't see the advantage of leaving
anything up to chance. Just explicitly disabling frame pointers is the
safest and cleanest option.

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>>> > see
>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>>
>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>>
>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>>> -fno-omit-frame-pointer?
>>>>>>
>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>>
>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>>> back if someone changes optimisation level or switches gcc to clang,
>>>>> etc).
>>>>>
>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>>> should fix the problem for all optimisation levels etc and avoids
>>>>> building the main strace binary differently depending on whether or
>>>>> not ptest is enabled.
>>>>
>>>> explicitly adding this option is a poor choice especially for debug
>>>> builds where we should
>>>> let the -On level decide and not explicitly ask for either
>>>> enable/disable frame-pointers
>>>> that will also make it compiler proof.
>>>
>>> Of course, we should let the compiler decide whenever it's possible to do so.
>>>
>>> Unfortunately there are cases like this one where frame pointers clash
>>> with inline assembler and we need to over-rule the compiler's choice.
>>
>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>> is the issue
>> where we have fallouts from default O options I agree we should teach
>> this to build
>> system and help the compiler
>
> Since there's NO situation where enabling frame pointers is going to
> work for this code + ARM + Thumb, I don't see the advantage of leaving
> anything up to chance. Just explicitly disabling frame pointers is the
> safest and cleanest option.

In that case what we are saying is that strace has wrong assumptions
I would think its best to change strace build system to demand this
option override instead of injecting it externally.

Re: [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>>> > see
>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>>
>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>>
>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>>> -fno-omit-frame-pointer?
>>>>>>
>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>>
>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>>> back if someone changes optimisation level or switches gcc to clang,
>>>>> etc).
>>>>>
>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>>> should fix the problem for all optimisation levels etc and avoids
>>>>> building the main strace binary differently depending on whether or
>>>>> not ptest is enabled.
>>>>
>>>> explicitly adding this option is a poor choice especially for debug
>>>> builds where we should
>>>> let the -On level decide and not explicitly ask for either
>>>> enable/disable frame-pointers
>>>> that will also make it compiler proof.
>>>
>>> Of course, we should let the compiler decide whenever it's possible to do so.
>>>
>>> Unfortunately there are cases like this one where frame pointers clash
>>> with inline assembler and we need to over-rule the compiler's choice.
>>
>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>> is the issue
>> where we have fallouts from default O options I agree we should teach
>> this to build
>> system and help the compiler
>
> Since there's NO situation where enabling frame pointers is going to
> work for this code + ARM + Thumb, I don't see the advantage of leaving
> anything up to chance. Just explicitly disabling frame pointers is the
> safest and cleanest option.

In that case what we are saying is that strace has wrong assumptions
I would think its best to change strace build system to demand this
option override instead of injecting it externally.

Re: [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>>>> > see
>>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>>>
>>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>>>
>>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>>>> -fno-omit-frame-pointer?
>>>>>>>
>>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>>>
>>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>>>> back if someone changes optimisation level or switches gcc to clang,
>>>>>> etc).
>>>>>>
>>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>>>> should fix the problem for all optimisation levels etc and avoids
>>>>>> building the main strace binary differently depending on whether or
>>>>>> not ptest is enabled.
>>>>>
>>>>> explicitly adding this option is a poor choice especially for debug
>>>>> builds where we should
>>>>> let the -On level decide and not explicitly ask for either
>>>>> enable/disable frame-pointers
>>>>> that will also make it compiler proof.
>>>>
>>>> Of course, we should let the compiler decide whenever it's possible to do so.
>>>>
>>>> Unfortunately there are cases like this one where frame pointers clash
>>>> with inline assembler and we need to over-rule the compiler's choice.
>>>
>>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>>> is the issue
>>> where we have fallouts from default O options I agree we should teach
>>> this to build
>>> system and help the compiler
>>
>> Since there's NO situation where enabling frame pointers is going to
>> work for this code + ARM + Thumb, I don't see the advantage of leaving
>> anything up to chance. Just explicitly disabling frame pointers is the
>> safest and cleanest option.
>
> In that case what we are saying is that strace has wrong assumptions
> I would think its best to change strace build system to demand this
> option override instead of injecting it externally.

There are many possible / better fixes if we want to patch the strace
sources or Makefiles. I'm not sure if Martin was signing up for that
though :-)

Re: [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>>>>> > see
>>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>>>
>>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>>>
>>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>>>> -fno-omit-frame-pointer?
>>>>>>>
>>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>>>
>>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>>>> back if someone changes optimisation level or switches gcc to clang,
>>>>>> etc).
>>>>>>
>>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>>>> should fix the problem for all optimisation levels etc and avoids
>>>>>> building the main strace binary differently depending on whether or
>>>>>> not ptest is enabled.
>>>>>
>>>>> explicitly adding this option is a poor choice especially for debug
>>>>> builds where we should
>>>>> let the -On level decide and not explicitly ask for either
>>>>> enable/disable frame-pointers
>>>>> that will also make it compiler proof.
>>>>
>>>> Of course, we should let the compiler decide whenever it's possible to do so.
>>>>
>>>> Unfortunately there are cases like this one where frame pointers clash
>>>> with inline assembler and we need to over-rule the compiler's choice.
>>>
>>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>>> is the issue
>>> where we have fallouts from default O options I agree we should teach
>>> this to build
>>> system and help the compiler
>>
>> Since there's NO situation where enabling frame pointers is going to
>> work for this code + ARM + Thumb, I don't see the advantage of leaving
>> anything up to chance. Just explicitly disabling frame pointers is the
>> safest and cleanest option.
>
> In that case what we are saying is that strace has wrong assumptions
> I would think its best to change strace build system to demand this
> option override instead of injecting it externally.

There are many possible / better fixes if we want to patch the strace
sources or Makefiles. I'm not sure if Martin was signing up for that
though :-)

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 6643 bytes --]

On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote:
> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> > > this, it build OK with sumo since the -std=gnu99 addition.
> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> > > before the last format character [-Werror=format-truncation=]
> > >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
> > >               ^~~
> > > 
> > 
> > something new, I will look into reproducing this.

The fix from you worked for me, thanks!

> > > I didn't get very far in testing, because our old kernel fails to build 
> > > with gcc8 and there are some other issues caused by other master 
> > > changes. But it doesn't look too bad (in my small test, lets see what 
> > > bitbake world will show), thanks a lot for new gcc.
> > > 
> > 
> > yes, older kernel needs fixes, especially to disable new warnings.
> > the mips/ppc fixes that I put out there might be helpful to cook up 
> > fixes for older kernels if running into same issues.
> 
> In this case it fails with Error: .err encountered for many drivers. It's not the same case as in:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html
> nor arm version of this change, both are already applied in our
> 4.4.3 based kernel.
> 
> I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't
> fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more.

Just FYI if someone needs similar fix, backporting this:
https://patchwork.kernel.org/patch/9170055/

fixed the issue for me, now I have successful kernel build.

The failing code was always in put_user calls, e.g. kernel/exit.s was showing:
@ 1581 "kernel-source/kernel/exit.c" 1
        .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif
        .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif
        .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif
        bl      __put_user_4
@ 0 "" 2

with the error triggered on the middle line.
/tmp/ccHq8ugv.s: Assembler messages:
/tmp/ccHq8ugv.s:1179: Error: .err encountered
/tmp/ccHq8ugv.s:1331: Error: .err encountered
/tmp/ccHq8ugv.s:4617: Error: .err encountered
/tmp/ccHq8ugv.s:6222: Error: .err encountered
/tmp/ccHq8ugv.s:8705: Error: .err encountered
/tmp/ccHq8ugv.s:14486: Error: .err encountered
/tmp/ccHq8ugv.s:14646: Error: .err encountered
/tmp/ccHq8ugv.s:14806: Error: .err encountered
/tmp/ccHq8ugv.s:14966: Error: .err encountered
/tmp/ccHq8ugv.s:15126: Error: .err encountered
/tmp/ccHq8ugv.s:15286: Error: .err encountered

That leaves only few issues in our internal components and strange failure with perf which fails to include various header files:
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
...

Cheers,

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 6643 bytes --]

On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote:
> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> > > this, it build OK with sumo since the -std=gnu99 addition.
> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> > > before the last format character [-Werror=format-truncation=]
> > >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
> > >               ^~~
> > > 
> > 
> > something new, I will look into reproducing this.

The fix from you worked for me, thanks!

> > > I didn't get very far in testing, because our old kernel fails to build 
> > > with gcc8 and there are some other issues caused by other master 
> > > changes. But it doesn't look too bad (in my small test, lets see what 
> > > bitbake world will show), thanks a lot for new gcc.
> > > 
> > 
> > yes, older kernel needs fixes, especially to disable new warnings.
> > the mips/ppc fixes that I put out there might be helpful to cook up 
> > fixes for older kernels if running into same issues.
> 
> In this case it fails with Error: .err encountered for many drivers. It's not the same case as in:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html
> nor arm version of this change, both are already applied in our
> 4.4.3 based kernel.
> 
> I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't
> fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more.

Just FYI if someone needs similar fix, backporting this:
https://patchwork.kernel.org/patch/9170055/

fixed the issue for me, now I have successful kernel build.

The failing code was always in put_user calls, e.g. kernel/exit.s was showing:
@ 1581 "kernel-source/kernel/exit.c" 1
        .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif
        .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif
        .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif
        bl      __put_user_4
@ 0 "" 2

with the error triggered on the middle line.
/tmp/ccHq8ugv.s: Assembler messages:
/tmp/ccHq8ugv.s:1179: Error: .err encountered
/tmp/ccHq8ugv.s:1331: Error: .err encountered
/tmp/ccHq8ugv.s:4617: Error: .err encountered
/tmp/ccHq8ugv.s:6222: Error: .err encountered
/tmp/ccHq8ugv.s:8705: Error: .err encountered
/tmp/ccHq8ugv.s:14486: Error: .err encountered
/tmp/ccHq8ugv.s:14646: Error: .err encountered
/tmp/ccHq8ugv.s:14806: Error: .err encountered
/tmp/ccHq8ugv.s:14966: Error: .err encountered
/tmp/ccHq8ugv.s:15126: Error: .err encountered
/tmp/ccHq8ugv.s:15286: Error: .err encountered

That leaves only few issues in our internal components and strange failure with perf which fails to include various header files:
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
...

Cheers,

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 17, 2018 at 3:46 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote:
>> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused
>> > > this, it build OK with sumo since the -std=gnu99 addition.
>> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
>> > > before the last format character [-Werror=format-truncation=]
>> > >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
>> > >               ^~~
>> > >
>> >
>> > something new, I will look into reproducing this.
>
> The fix from you worked for me, thanks!

There is a followup here which now doesnt need local patch

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=0924a69244892097f60adbf6c7f576375bea7870

> Just FYI if someone needs similar fix, backporting this:
> https://patchwork.kernel.org/patch/9170055/
>
> fixed the issue for me, now I have successful kernel build.
>
> The failing code was always in put_user calls, e.g. kernel/exit.s was showing:
> @ 1581 "kernel-source/kernel/exit.c" 1
>         .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif
>         .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif
>         .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif
>         bl      __put_user_4
> @ 0 "" 2
>
> with the error triggered on the middle line.
> /tmp/ccHq8ugv.s: Assembler messages:
> /tmp/ccHq8ugv.s:1179: Error: .err encountered
> /tmp/ccHq8ugv.s:1331: Error: .err encountered
> /tmp/ccHq8ugv.s:4617: Error: .err encountered
> /tmp/ccHq8ugv.s:6222: Error: .err encountered
> /tmp/ccHq8ugv.s:8705: Error: .err encountered
> /tmp/ccHq8ugv.s:14486: Error: .err encountered
> /tmp/ccHq8ugv.s:14646: Error: .err encountered
> /tmp/ccHq8ugv.s:14806: Error: .err encountered
> /tmp/ccHq8ugv.s:14966: Error: .err encountered
> /tmp/ccHq8ugv.s:15126: Error: .err encountered
> /tmp/ccHq8ugv.s:15286: Error: .err encountered
>
> That leaves only few issues in our internal components and strange failure with perf which fails to include various header files:

perf is building file for qemux86 on o-core
I wonder if this is an issue related to your
kernel version.


>
> Cheers,

Re: [RFT] GCC 8.1

[Khem Raj]

On Thu, May 17, 2018 at 3:46 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote:
>> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused
>> > > this, it build OK with sumo since the -std=gnu99 addition.
>> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
>> > > before the last format character [-Werror=format-truncation=]
>> > >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
>> > >               ^~~
>> > >
>> >
>> > something new, I will look into reproducing this.
>
> The fix from you worked for me, thanks!

There is a followup here which now doesnt need local patch

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=0924a69244892097f60adbf6c7f576375bea7870

> Just FYI if someone needs similar fix, backporting this:
> https://patchwork.kernel.org/patch/9170055/
>
> fixed the issue for me, now I have successful kernel build.
>
> The failing code was always in put_user calls, e.g. kernel/exit.s was showing:
> @ 1581 "kernel-source/kernel/exit.c" 1
>         .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif
>         .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif
>         .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif
>         bl      __put_user_4
> @ 0 "" 2
>
> with the error triggered on the middle line.
> /tmp/ccHq8ugv.s: Assembler messages:
> /tmp/ccHq8ugv.s:1179: Error: .err encountered
> /tmp/ccHq8ugv.s:1331: Error: .err encountered
> /tmp/ccHq8ugv.s:4617: Error: .err encountered
> /tmp/ccHq8ugv.s:6222: Error: .err encountered
> /tmp/ccHq8ugv.s:8705: Error: .err encountered
> /tmp/ccHq8ugv.s:14486: Error: .err encountered
> /tmp/ccHq8ugv.s:14646: Error: .err encountered
> /tmp/ccHq8ugv.s:14806: Error: .err encountered
> /tmp/ccHq8ugv.s:14966: Error: .err encountered
> /tmp/ccHq8ugv.s:15126: Error: .err encountered
> /tmp/ccHq8ugv.s:15286: Error: .err encountered
>
> That leaves only few issues in our internal components and strange failure with perf which fails to include various header files:

perf is building file for qemux86 on o-core
I wonder if this is an issue related to your
kernel version.


>
> Cheers,

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]

> That leaves only few issues in our internal components and strange failure with perf which fails to include various header files:
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
> ...

This issue wasn't caused by gcc upgrade, it was caused by:
https://patchwork.openembedded.org/patch/150269/
which was included in the same batch of updates when I've included
these RFT changes.

I've sent separate fix for perf with slightly longer explanation what
was wrong:
https://patchwork.openembedded.org/patch/151017/

Now I got a bit further with testing again, remaining 3 issues in public
recipes:

gcc-sanitizers/8.1.0-r0 fails to build with qemuarm (with thumb
enabled):
{standard input}: Assembler messages:
{standard input}:5724: Error: lo register required -- `ldr ip,[sp],#8'
make[2]: *** [sanitizer_linux.lo] Error 1

qtbase/5.6.3+gitAUTOINC+e6f8b072d2-r0 fails to build with qemuarm (with
thumb
enabled):
{standard input}: Assembler messages:
{standard input}: Error: unaligned opcodes detected in executable segment
make[2]: *** [.obj/qdrawhelper.o] Error 1

lib32-glibc-initial/2.27-r0 fails to build with multilib
checking installed Linux kernel header files... missing or too old!
configure: error: GNU libc requires kernel header files from
Linux 3.2.0 or later to be installed before configuring.
The kernel header files are found usually in /usr/include/asm and
/usr/include/linux; make sure these directories use files from
Linux 3.2.0 or later.  This check uses <linux/version.h>, so
make sure that file was built correctly when installing the kernel header
files.  To use kernel headers not from /usr/include/linux, use the
configure option --with-headers.
WARNING: exit code 1 from a shell command.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]

> That leaves only few issues in our internal components and strange failure with perf which fails to include various header files:
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply
> ...

This issue wasn't caused by gcc upgrade, it was caused by:
https://patchwork.openembedded.org/patch/150269/
which was included in the same batch of updates when I've included
these RFT changes.

I've sent separate fix for perf with slightly longer explanation what
was wrong:
https://patchwork.openembedded.org/patch/151017/

Now I got a bit further with testing again, remaining 3 issues in public
recipes:

gcc-sanitizers/8.1.0-r0 fails to build with qemuarm (with thumb
enabled):
{standard input}: Assembler messages:
{standard input}:5724: Error: lo register required -- `ldr ip,[sp],#8'
make[2]: *** [sanitizer_linux.lo] Error 1

qtbase/5.6.3+gitAUTOINC+e6f8b072d2-r0 fails to build with qemuarm (with
thumb
enabled):
{standard input}: Assembler messages:
{standard input}: Error: unaligned opcodes detected in executable segment
make[2]: *** [.obj/qdrawhelper.o] Error 1

lib32-glibc-initial/2.27-r0 fails to build with multilib
checking installed Linux kernel header files... missing or too old!
configure: error: GNU libc requires kernel header files from
Linux 3.2.0 or later to be installed before configuring.
The kernel header files are found usually in /usr/include/asm and
/usr/include/linux; make sure these directories use files from
Linux 3.2.0 or later.  This check uses <linux/version.h>, so
make sure that file was built correctly when installing the kernel header
files.  To use kernel headers not from /usr/include/linux, use the
configure option --with-headers.
WARNING: exit code 1 from a shell command.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Dan McGregor]

On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend :)
>

Thanks for this. The only two issues I noticed are that the
Wandboard's kernel doesn't compile with gcc 8.1, and gcc-sanitizers
now throws a packaging error on (at least) x86_64.
${libdir}/liblsan_preinit.o is a new file that should go into
liblsan-dev.

> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFT] GCC 8.1

[Dan McGregor]

On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend :)
>

Thanks for this. The only two issues I noticed are that the
Wandboard's kernel doesn't compile with gcc 8.1, and gcc-sanitizers
now throws a packaging error on (at least) x86_64.
${libdir}/liblsan_preinit.o is a new file that should go into
liblsan-dev.

> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

Hi Dan,

Thanks for testing

On 5/10/18 7:34 AM, Dan McGregor wrote:
> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
> 
> Thanks for this. The only two issues I noticed are that the
> Wandboard's kernel doesn't compile with gcc 8.1,


what errors do you see ?

  and gcc-sanitizers
> now throws a packaging error on (at least) x86_64.
> ${libdir}/liblsan_preinit.o is a new file that should go into
> liblsan-dev.

That seems to be the case, I wonder why my world build for qemux86_64 
did not find this error. I would like to reproduce this and the fix is 
then simple.

> 
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFT] GCC 8.1

[Khem Raj]

Hi Dan,

Thanks for testing

On 5/10/18 7:34 AM, Dan McGregor wrote:
> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
> 
> Thanks for this. The only two issues I noticed are that the
> Wandboard's kernel doesn't compile with gcc 8.1,


what errors do you see ?

  and gcc-sanitizers
> now throws a packaging error on (at least) x86_64.
> ${libdir}/liblsan_preinit.o is a new file that should go into
> liblsan-dev.

That seems to be the case, I wonder why my world build for qemux86_64 
did not find this error. I would like to reproduce this and the fix is 
then simple.

> 
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] GCC 8.1

[Dan McGregor]

On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote:
> Hi Dan,
>
> Thanks for testing
>
> On 5/10/18 7:34 AM, Dan McGregor wrote:
>>
>> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> Hi All
>>>
>>> As you might have noticed that gcc 8.1 was released this week, I am
>>> calling out for some testing help on testing branch so we can weed out
>>> issues you might see in your setups. so if you have your
>>> builders idling over weekend, then you know what they can do this weekend
>>> :)
>>>
>>
>> Thanks for this. The only two issues I noticed are that the
>> Wandboard's kernel doesn't compile with gcc 8.1,
>
>
>
> what errors do you see ?

I expect the standard "Linux 4.1" errors. A bunch of ignored
attributes and incompatible type aliases:

tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1:
warning: ignoring attribute 'noreturn' because it conflicts with
attribute 'const' [-Wattributes]
 int ____ilog2_NaN(void)

tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18:
warning: 'sys_clone' alias between functions of incompatible types
'long int(long unsigned int,  long unsigned int,  int *, int,  int *)'
and 'long int(long int,  long int,  long int,  long int,  long int)'
[-Wattribute-alias]
  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \

I can give you the full compile log if you'd like, but I think others
want it kept off the list.

>
>  and gcc-sanitizers
>>
>> now throws a packaging error on (at least) x86_64.
>> ${libdir}/liblsan_preinit.o is a new file that should go into
>> liblsan-dev.
>
>
> That seems to be the case, I wonder why my world build for qemux86_64 did
> not find this error. I would like to reproduce this and the fix is then
> simple.

My x86_64 build was multilib enabled. I doubt that had anything to do
with it, but I suppose it's possible.

>
>
>>
>>> Highlighted changes are
>>>
>>> https://gcc.gnu.org/gcc-8/changes.html
>>>
>>> and porting doc is
>>>
>>> https://gcc.gnu.org/gcc-8/porting_to.html
>>>
>>> The branch is here
>>>
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>>
>>> Its uptodate on top of current master oe-core
>>>
>>> May fourth be with you !!
>>>
>>> Cheers!
>>>
>>> -Khem
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFT] GCC 8.1

[Dan McGregor]

On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote:
> Hi Dan,
>
> Thanks for testing
>
> On 5/10/18 7:34 AM, Dan McGregor wrote:
>>
>> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> Hi All
>>>
>>> As you might have noticed that gcc 8.1 was released this week, I am
>>> calling out for some testing help on testing branch so we can weed out
>>> issues you might see in your setups. so if you have your
>>> builders idling over weekend, then you know what they can do this weekend
>>> :)
>>>
>>
>> Thanks for this. The only two issues I noticed are that the
>> Wandboard's kernel doesn't compile with gcc 8.1,
>
>
>
> what errors do you see ?

I expect the standard "Linux 4.1" errors. A bunch of ignored
attributes and incompatible type aliases:

tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1:
warning: ignoring attribute 'noreturn' because it conflicts with
attribute 'const' [-Wattributes]
 int ____ilog2_NaN(void)

tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18:
warning: 'sys_clone' alias between functions of incompatible types
'long int(long unsigned int,  long unsigned int,  int *, int,  int *)'
and 'long int(long int,  long int,  long int,  long int,  long int)'
[-Wattribute-alias]
  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \

I can give you the full compile log if you'd like, but I think others
want it kept off the list.

>
>  and gcc-sanitizers
>>
>> now throws a packaging error on (at least) x86_64.
>> ${libdir}/liblsan_preinit.o is a new file that should go into
>> liblsan-dev.
>
>
> That seems to be the case, I wonder why my world build for qemux86_64 did
> not find this error. I would like to reproduce this and the fix is then
> simple.

My x86_64 build was multilib enabled. I doubt that had anything to do
with it, but I suppose it's possible.

>
>
>>
>>> Highlighted changes are
>>>
>>> https://gcc.gnu.org/gcc-8/changes.html
>>>
>>> and porting doc is
>>>
>>> https://gcc.gnu.org/gcc-8/porting_to.html
>>>
>>> The branch is here
>>>
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>>
>>> Its uptodate on top of current master oe-core
>>>
>>> May fourth be with you !!
>>>
>>> Cheers!
>>>
>>> -Khem
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]

On Mon, May 14, 2018 at 10:33:41AM -0600, Dan McGregor wrote:
> On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote:
> > Hi Dan,
> >
> > Thanks for testing
> >
> > On 5/10/18 7:34 AM, Dan McGregor wrote:
> >>
> >> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
> >>>
> >>> Hi All
> >>>
> >>> As you might have noticed that gcc 8.1 was released this week, I am
> >>> calling out for some testing help on testing branch so we can weed out
> >>> issues you might see in your setups. so if you have your
> >>> builders idling over weekend, then you know what they can do this weekend
> >>> :)
> >>>
> >>
> >> Thanks for this. The only two issues I noticed are that the
> >> Wandboard's kernel doesn't compile with gcc 8.1,
> >
> >
> >
> > what errors do you see ?
> 
> I expect the standard "Linux 4.1" errors. A bunch of ignored
> attributes and incompatible type aliases:
> 
> tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1:
> warning: ignoring attribute 'noreturn' because it conflicts with
> attribute 'const' [-Wattributes]
>  int ____ilog2_NaN(void)

Try backporting this change:
https://github.com/torvalds/linux/commit/474c90156c8dcc2fa815e6716cc9394d7930cb9c

> tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18:
> warning: 'sys_clone' alias between functions of incompatible types
> 'long int(long unsigned int,  long unsigned int,  int *, int,  int *)'
> and 'long int(long int,  long int,  long int,  long int,  long int)'
> [-Wattribute-alias]
>   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> 
> I can give you the full compile log if you'd like, but I think others
> want it kept off the list.
> 
> >
> >  and gcc-sanitizers
> >>
> >> now throws a packaging error on (at least) x86_64.
> >> ${libdir}/liblsan_preinit.o is a new file that should go into
> >> liblsan-dev.
> >
> >
> > That seems to be the case, I wonder why my world build for qemux86_64 did
> > not find this error. I would like to reproduce this and the fix is then
> > simple.
> 
> My x86_64 build was multilib enabled. I doubt that had anything to do
> with it, but I suppose it's possible.
> 
> >
> >
> >>
> >>> Highlighted changes are
> >>>
> >>> https://gcc.gnu.org/gcc-8/changes.html
> >>>
> >>> and porting doc is
> >>>
> >>> https://gcc.gnu.org/gcc-8/porting_to.html
> >>>
> >>> The branch is here
> >>>
> >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
> >>>
> >>> Its uptodate on top of current master oe-core
> >>>
> >>> May fourth be with you !!
> >>>
> >>> Cheers!
> >>>
> >>> -Khem
> >>> --
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [RFT] GCC 8.1

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]

On Mon, May 14, 2018 at 10:33:41AM -0600, Dan McGregor wrote:
> On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote:
> > Hi Dan,
> >
> > Thanks for testing
> >
> > On 5/10/18 7:34 AM, Dan McGregor wrote:
> >>
> >> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote:
> >>>
> >>> Hi All
> >>>
> >>> As you might have noticed that gcc 8.1 was released this week, I am
> >>> calling out for some testing help on testing branch so we can weed out
> >>> issues you might see in your setups. so if you have your
> >>> builders idling over weekend, then you know what they can do this weekend
> >>> :)
> >>>
> >>
> >> Thanks for this. The only two issues I noticed are that the
> >> Wandboard's kernel doesn't compile with gcc 8.1,
> >
> >
> >
> > what errors do you see ?
> 
> I expect the standard "Linux 4.1" errors. A bunch of ignored
> attributes and incompatible type aliases:
> 
> tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1:
> warning: ignoring attribute 'noreturn' because it conflicts with
> attribute 'const' [-Wattributes]
>  int ____ilog2_NaN(void)

Try backporting this change:
https://github.com/torvalds/linux/commit/474c90156c8dcc2fa815e6716cc9394d7930cb9c

> tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18:
> warning: 'sys_clone' alias between functions of incompatible types
> 'long int(long unsigned int,  long unsigned int,  int *, int,  int *)'
> and 'long int(long int,  long int,  long int,  long int,  long int)'
> [-Wattribute-alias]
>   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> 
> I can give you the full compile log if you'd like, but I think others
> want it kept off the list.
> 
> >
> >  and gcc-sanitizers
> >>
> >> now throws a packaging error on (at least) x86_64.
> >> ${libdir}/liblsan_preinit.o is a new file that should go into
> >> liblsan-dev.
> >
> >
> > That seems to be the case, I wonder why my world build for qemux86_64 did
> > not find this error. I would like to reproduce this and the fix is then
> > simple.
> 
> My x86_64 build was multilib enabled. I doubt that had anything to do
> with it, but I suppose it's possible.
> 
> >
> >
> >>
> >>> Highlighted changes are
> >>>
> >>> https://gcc.gnu.org/gcc-8/changes.html
> >>>
> >>> and porting doc is
> >>>
> >>> https://gcc.gnu.org/gcc-8/porting_to.html
> >>>
> >>> The branch is here
> >>>
> >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
> >>>
> >>> Its uptodate on top of current master oe-core
> >>>
> >>> May fourth be with you !!
> >>>
> >>> Cheers!
> >>>
> >>> -Khem
> >>> --
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [OE-core] [RFT] GCC 8.1

[Burton, Ross]

I threw the branch at the Yocto Project autobuilder today, produced a
number of failures:

http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit

Ross

On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFT] GCC 8.1

[Burton, Ross]

I threw the branch at the Yocto Project autobuilder today, produced a
number of failures:

http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit

Ross

On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

Hi Ross

Thanks for testing

I looked at failures and one of them is

RESULTS - kernelmodule.KernelModuleTest.test_kernel_module - Testcase
1541: FAILED

and this is the compile error.

pager.c: In function 'pager_preexec':
pager.c:36:12: error: passing argument 2 to restrict-qualified
parameter aliases with argument 4 [-Werror=restrict]
  select(1, &in, NULL, &in, NULL);
            ^~~        ~~~
cc1: all warnings being treated as errors
mv: cannot stat '/usr/src/kernel/tools/objtool/.pager.o.tmp': No such
file or directory


Firstly I must say that I am impressed with autotest, We are building
on-device toolchain and then downloading a kernel and building it to
test i.. bravo

Problem here is that poky pins linux-yocto to 4.14, with gcc8 we need
to use 4.15.x
eventually 4.14 will get fixed but until then use 4.15,
the test subject component that is being compiled
is not ported to gcc-8, not sure how we can improve it. Is it
compiling linux-yocto kmods ? or external kmod ? We need to patch the
test before building,

I think the mesa error is new with mesa-18 I havent seen this on my
end. Its showing up when we enable llvmpipe which is not general
default so it might not happen in general.

selftest is failing like this

| Copying files into the device: __populate_fs: Could not allocate
block in ext2 filesystem while writing file "ldconfig"
| mkfs.ext4: Could not allocate block in ext2 filesystem while
populating file system
| WARNING: /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/run.do_image_ext4.15615:1
exit 1 from 'mkfs.$fstype -F $extra_imagecmd
/tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64-20180511212710.rootfs.$fstype
-d /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs'

not sure if I understand it fully but it sems system ran out of disk space.


On Fri, May 11, 2018 at 3:05 PM, Burton, Ross <ross.burton@intel.com> wrote:
> I threw the branch at the Yocto Project autobuilder today, produced a
> number of failures:
>
> http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit
>
> Ross
>
> On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFT] GCC 8.1

[Khem Raj]

Hi Ross

Thanks for testing

I looked at failures and one of them is

RESULTS - kernelmodule.KernelModuleTest.test_kernel_module - Testcase
1541: FAILED

and this is the compile error.

pager.c: In function 'pager_preexec':
pager.c:36:12: error: passing argument 2 to restrict-qualified
parameter aliases with argument 4 [-Werror=restrict]
  select(1, &in, NULL, &in, NULL);
            ^~~        ~~~
cc1: all warnings being treated as errors
mv: cannot stat '/usr/src/kernel/tools/objtool/.pager.o.tmp': No such
file or directory


Firstly I must say that I am impressed with autotest, We are building
on-device toolchain and then downloading a kernel and building it to
test i.. bravo

Problem here is that poky pins linux-yocto to 4.14, with gcc8 we need
to use 4.15.x
eventually 4.14 will get fixed but until then use 4.15,
the test subject component that is being compiled
is not ported to gcc-8, not sure how we can improve it. Is it
compiling linux-yocto kmods ? or external kmod ? We need to patch the
test before building,

I think the mesa error is new with mesa-18 I havent seen this on my
end. Its showing up when we enable llvmpipe which is not general
default so it might not happen in general.

selftest is failing like this

| Copying files into the device: __populate_fs: Could not allocate
block in ext2 filesystem while writing file "ldconfig"
| mkfs.ext4: Could not allocate block in ext2 filesystem while
populating file system
| WARNING: /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/run.do_image_ext4.15615:1
exit 1 from 'mkfs.$fstype -F $extra_imagecmd
/tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64-20180511212710.rootfs.$fstype
-d /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs'

not sure if I understand it fully but it sems system ran out of disk space.


On Fri, May 11, 2018 at 3:05 PM, Burton, Ross <ross.burton@intel.com> wrote:
> I threw the branch at the Yocto Project autobuilder today, produced a
> number of failures:
>
> http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit
>
> Ross
>
> On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] GCC 8.1

[Khem Raj]

Hi Ross

I pushed a few more fixes to branch which fixes

kernel build issue
ovmf build issue
python2 build issue (your fix)

I could not reproduce the mesa issues that is shown on AB

With this I think we should be in better shape. Can you retry

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master

Once again and please bump the kernel version in poky to default by 
removing the pinning

meta-poky/conf/distro/poky-lsb.conf:PREFERRED_VERSION_linux-yocto_linuxstdbase 
?= "4.14%"
meta-poky/conf/distro/poky-tiny.conf:PREFERRED_VERSION_linux-yocto-tiny 
?= "4.14%"
meta-poky/conf/distro/poky.conf:PREFERRED_VERSION_linux-yocto ?= "4.14%"


Thanks
-Khem



On 5/11/18 3:05 PM, Burton, Ross wrote:
> I threw the branch at the Yocto Project autobuilder today, produced a
> number of failures:
> 
> http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit
> 
> Ross
> 
> On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFT] GCC 8.1

[Khem Raj]

Hi Ross

I pushed a few more fixes to branch which fixes

kernel build issue
ovmf build issue
python2 build issue (your fix)

I could not reproduce the mesa issues that is shown on AB

With this I think we should be in better shape. Can you retry

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master

Once again and please bump the kernel version in poky to default by 
removing the pinning

meta-poky/conf/distro/poky-lsb.conf:PREFERRED_VERSION_linux-yocto_linuxstdbase 
?= "4.14%"
meta-poky/conf/distro/poky-tiny.conf:PREFERRED_VERSION_linux-yocto-tiny 
?= "4.14%"
meta-poky/conf/distro/poky.conf:PREFERRED_VERSION_linux-yocto ?= "4.14%"


Thanks
-Khem



On 5/11/18 3:05 PM, Burton, Ross wrote:
> I threw the branch at the Yocto Project autobuilder today, produced a
> number of failures:
> 
> http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit
> 
> Ross
> 
> On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote:
>> Hi All
>>
>> As you might have noticed that gcc 8.1 was released this week, I am
>> calling out for some testing help on testing branch so we can weed out
>> issues you might see in your setups. so if you have your
>> builders idling over weekend, then you know what they can do this weekend :)
>>
>> Highlighted changes are
>>
>> https://gcc.gnu.org/gcc-8/changes.html
>>
>> and porting doc is
>>
>> https://gcc.gnu.org/gcc-8/porting_to.html
>>
>> The branch is here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>>
>> Its uptodate on top of current master oe-core
>>
>> May fourth be with you !!
>>
>> Cheers!
>>
>> -Khem
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core