| Message ID | 1472978990-14884-1-git-send-email-romain.naour@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Hi Romain, On Sun, Sep 04, 2016 at 10:49:50AM +0200, Romain Naour wrote: > ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context > ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context > 2 bad relocscollect2: error: ld returned 1 exit status > > Binutils build fine with -O1, -O2 or -O3. Is there an upstream bug report we can refer to? > Fixes: > http://autobuild.buildroot.net/results/e72/e727e6e9cf361acc786acec192a88f5f5444a2f6 > > Signed-off-by: Romain Naour <romain.naour@gmail.com> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > package/binutils/binutils.mk | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk > index ff90a16..6946e7e 100644 > --- a/package/binutils/binutils.mk > +++ b/package/binutils/binutils.mk > @@ -77,6 +77,12 @@ ifeq ($(BR2_bfin),y) > BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O1" > endif > > +# Workaround a build issue with -Os on Thumb-2 only platforms > +# (such as Cortex-M). (Binutils 2.25.1 and 2.26.1) > +ifeq ($(BR2_ARM_CPU_HAS_ARM)$(BR2_OPTIMIZE_S),yy) > +BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O1" Isn't -O2 the more "standard" optimization option? > +endif baruch
Hi Baruch, Le 04/09/2016 à 10:55, Baruch Siach a écrit : > Hi Romain, > > On Sun, Sep 04, 2016 at 10:49:50AM +0200, Romain Naour wrote: >> ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context >> ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context >> 2 bad relocscollect2: error: ld returned 1 exit status >> >> Binutils build fine with -O1, -O2 or -O3. > > Is there an upstream bug report we can refer to? No, I can't find any bug report. Also I don't understand the meaning of this error, I just try some other build options and figured out that the issue was caused by -Os. > >> Fixes: >> http://autobuild.buildroot.net/results/e72/e727e6e9cf361acc786acec192a88f5f5444a2f6 >> >> Signed-off-by: Romain Naour <romain.naour@gmail.com> >> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> >> --- >> package/binutils/binutils.mk | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk >> index ff90a16..6946e7e 100644 >> --- a/package/binutils/binutils.mk >> +++ b/package/binutils/binutils.mk >> @@ -77,6 +77,12 @@ ifeq ($(BR2_bfin),y) >> BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O1" >> endif >> >> +# Workaround a build issue with -Os on Thumb-2 only platforms >> +# (such as Cortex-M). (Binutils 2.25.1 and 2.26.1) >> +ifeq ($(BR2_ARM_CPU_HAS_ARM)$(BR2_OPTIMIZE_S),yy) >> +BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O1" > > Isn't -O2 the more "standard" optimization option? Yes maybe, it's just because I borrowed the same line above for Blackfin :) As I said on the commit log, Binutils build fine with O1,O2 and O3 so use O2 if it's more "standard" optimization option. Thanks! Best regards, Romain > >> +endif > > baruch >
Hello, On Sun, 4 Sep 2016 10:49:50 +0200, Romain Naour wrote: > +# Workaround a build issue with -Os on Thumb-2 only platforms > +# (such as Cortex-M). (Binutils 2.25.1 and 2.26.1) > +ifeq ($(BR2_ARM_CPU_HAS_ARM)$(BR2_OPTIMIZE_S),yy) Unless I'm missing something, I don't see how the code is matching the comment above. Your comment is "with Thumb-2 only platforms, there is an issue with the -Os optimization level" while your condition is "with ARM-capable platforms, there is an issue with the -Os optimization level". Are you sure what want is not: ifeq ($(BR2_ARM_CPU_HAS_ARM):$(BR2_OPTIMIZE_S),:y) .... endif Also, I'm a bit surprised this happens only on Thumb-2 only platforms, and not on all ARM platforms, when Thumb-2 is chosen. But I'm far from understanding all the fine details of relocations. Thanks, Thomas
Hi Thomas, Le 04/09/2016 à 14:43, Thomas Petazzoni a écrit : > Hello, > > On Sun, 4 Sep 2016 10:49:50 +0200, Romain Naour wrote: > >> +# Workaround a build issue with -Os on Thumb-2 only platforms >> +# (such as Cortex-M). (Binutils 2.25.1 and 2.26.1) >> +ifeq ($(BR2_ARM_CPU_HAS_ARM)$(BR2_OPTIMIZE_S),yy) > > Unless I'm missing something, I don't see how the code is matching the > comment above. Your comment is "with Thumb-2 only platforms, there is > an issue with the -Os optimization level" while your condition is "with > ARM-capable platforms, there is an issue with the -Os optimization > level". > > Are you sure what want is not: > > ifeq ($(BR2_ARM_CPU_HAS_ARM):$(BR2_OPTIMIZE_S),:y) > .... > endif You're right, this is what I wanted to do. :-/ > > Also, I'm a bit surprised this happens only on Thumb-2 only platforms, > and not on all ARM platforms, when Thumb-2 is chosen. But I'm far from > understanding all the fine details of relocations. Neither do I. I tried with an ARM toolchain with BR2_ARM_INSTRUCTIONS_THUMB2 set and with the same build options (static only and Os) but Binutils build fine. I'll send a v2 shortly. Best regards, Romain > > Thanks, > > Thomas >
On Sun, Sep 4, 2016 at 5:43 AM Thomas Petazzoni < thomas.petazzoni@free-electrons.com> wrote: > On Sun, 4 Sep 2016 10:49:50 +0200, Romain Naour wrote: > > > +# Workaround a build issue with -Os on Thumb-2 only platforms > > +# (such as Cortex-M). (Binutils 2.25.1 and 2.26.1) > > I'm a bit surprised this happens only on Thumb-2 only platforms, > and not on all ARM platforms, when Thumb-2 is chosen. But I'm far from > understanding all the fine details of relocations. > I found a bug report about a similar error in a different package, and I saw it on a non-Thumb-2 platform (ARM9). I'll send more details when I'm in the office on Tuesday, as I don't have the error message, package name, or bug report in front of me. Regards, Nicholas
Please disregard my previous message: On Sun, Sep 4, 2016 at 10:52 AM Nicholas Walton <nicholas.walton@gmail.com> wrote: > I found a bug report about a similar error in a different package, and I > saw it on a non-Thumb-2 platform (ARM9). > The error I was remembering was bad code generation causing a segfault (which I saw in libfb.so). Restricting xserver_xorg-server to -O2 (5500211e201f84b6e2ce0dd5ff3013fb92628860) fixed it. I suspect the root cause was related to *Bug 63346* <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63346> - "xserver_xorg-server-1.15.1 crash on RaspberryPi . . . gcc-4.9", and/or* Bug 69614* <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614> - "[4.9/5 Regression] wrong code with -Os -fno-expensive . . . @ armv7a". Bug 69614 is fixed in 6.0 and the patch was backported to 5, but not to 4.9. Apologies, Nicholas Walton
diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk index ff90a16..6946e7e 100644 --- a/package/binutils/binutils.mk +++ b/package/binutils/binutils.mk @@ -77,6 +77,12 @@ ifeq ($(BR2_bfin),y) BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O1" endif +# Workaround a build issue with -Os on Thumb-2 only platforms +# (such as Cortex-M). (Binutils 2.25.1 and 2.26.1) +ifeq ($(BR2_ARM_CPU_HAS_ARM)$(BR2_OPTIMIZE_S),yy) +BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O1" +endif + # Install binutils after busybox to prefer full-blown utilities ifeq ($(BR2_PACKAGE_BUSYBOX),y) BINUTILS_DEPENDENCIES += busybox
ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context 2 bad relocscollect2: error: ld returned 1 exit status Binutils build fine with -O1, -O2 or -O3. Fixes: http://autobuild.buildroot.net/results/e72/e727e6e9cf361acc786acec192a88f5f5444a2f6 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- package/binutils/binutils.mk | 6 ++++++ 1 file changed, 6 insertions(+)