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).
>