| Message ID | 20190112175505.14348-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [v2,1/1] gnuchess: needs -fPIC | expand |
Hello Fabrice, On Sat, 12 Jan 2019 18:55:05 +0100, Fabrice Fontaine wrote: > When building with -O2 (or -O3) on ARM cortex-M cpus, link fails on: > > /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/bin/arm-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wl,-elf2flt -static -Wl,-elf2flt -static -Wl,-elf2flt -static -o gnuchess main.o components.o frontend/libfrontend.a adapter/libadapter.a engine/libengine.a -lreadline -lncurses > 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 > 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 > 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 > ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context > > To fix this, pas -fPIC unconditionnally > > Fixes: > - http://autobuild.buildroot.org/results/7918757b255ed41609609d2083c2d8904ff3136e > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> I'm sorry but this doesn't make sense to me. -fPIC is for Position Independent Code, which is needed when building shared libraries. Here we are building with -static on Cortex-M which doesn't even have support for shared libraries. So building with -fPIC doesn't make sense I believe. It seems to be more a workaround than a real fix. Perhaps this should be discussed with upstream binutils, or at least a proper investigation be done about those relocation types ? Best regards, Thomas
On 13/01/2019 14:13, Thomas Petazzoni wrote: > Hello Fabrice, > > On Sat, 12 Jan 2019 18:55:05 +0100, Fabrice Fontaine wrote: >> When building with -O2 (or -O3) on ARM cortex-M cpus, link fails on: >> >> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/bin/arm-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wl,-elf2flt -static -Wl,-elf2flt -static -Wl,-elf2flt -static -o gnuchess main.o components.o frontend/libfrontend.a adapter/libadapter.a engine/libengine.a -lreadline -lncurses >> 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 >> 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 >> 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 >> ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context >> >> To fix this, pas -fPIC unconditionnally >> >> Fixes: >> - http://autobuild.buildroot.org/results/7918757b255ed41609609d2083c2d8904ff3136e >> >> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > > I'm sorry but this doesn't make sense to me. -fPIC is for Position > Independent Code, which is needed when building shared libraries. Here > we are building with -static on Cortex-M which doesn't even have > support for shared libraries. So building with -fPIC doesn't make sense > I believe. It seems to be more a workaround than a real fix. > > Perhaps this should be discussed with upstream binutils, or at least a > proper investigation be done about those relocation types ? Or we could argue that gnuchess on Cortex-M probably isn't that essential, and just put an architecture dependency... Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: >> I'm sorry but this doesn't make sense to me. -fPIC is for Position >> Independent Code, which is needed when building shared libraries. Here >> we are building with -static on Cortex-M which doesn't even have >> support for shared libraries. So building with -fPIC doesn't make sense >> I believe. It seems to be more a workaround than a real fix. >> >> Perhaps this should be discussed with upstream binutils, or at least a >> proper investigation be done about those relocation types ? > Or we could argue that gnuchess on Cortex-M probably isn't that essential, and > just put an architecture dependency... That is also OK with me.
Hello, On Sun, 13 Jan 2019 14:13:29 +0100 Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > I'm sorry but this doesn't make sense to me. -fPIC is for Position > Independent Code, which is needed when building shared libraries. Here > we are building with -static on Cortex-M which doesn't even have > support for shared libraries. So building with -fPIC doesn't make sense > I believe. It seems to be more a workaround than a real fix. > > Perhaps this should be discussed with upstream binutils, or at least a > proper investigation be done about those relocation types ? OK, so I had a closer look into this, finally. What happens from my understanding is that building gnuchess with optimization enabled (at least -O2) causes some movt/movw instructions to be generated in the move.o object file: 380: f240 0c00 movw ip, #0 388: f2c0 0c00 movt ip, #0 These instructions refer to a global variable called PawnHashKey, declared in another C file. Because of it being a global variable, a relocation is added for those instructions: 00000380 00003f2f R_ARM_THM_MOVW_AB 00000000 PawnHashKey 00000388 00003f30 R_ARM_THM_MOVT_AB 00000000 PawnHashKey 00000464 00003f2f R_ARM_THM_MOVW_AB 00000000 PawnHashKey 00000470 00003f30 R_ARM_THM_MOVT_AB 00000000 PawnHashKey And the problem is that those special relocation types are not understood by elf2flt. If you change the optimization flag to -O0, then the problem doesn't occur because these movt/movw instructions are not generated. The fact that -fPIC also works around the problem is probably due to the fact that in a Position Independent logic, such relocations maybe don't exist (?) or perhaps it was pure luck that the generated code was different. Interestingly, Romain Naour also faced this issue a while ago when building binutils on Cortex-M, and that lead to commit 49f574237983ae2e69e4a4c43df7be98902a63be. Romain reported a bug to binutils (https://sourceware.org/bugzilla/show_bug.cgi?id=20552), but now I believe that the bug report is incorrect: the actual issue is in elf2flt. For example, the Linux kernel module loading code has support for these relocation types: https://elixir.bootlin.com/linux/v4.5/source/arch/arm/kernel/module.c#L258 so they seem to be legitimate. Therefore I guess the issue is in elf2flt, and I reported a bug at https://github.com/uclinux-dev/elf2flt/issues/11. In the mean time, I'm not sure what to do. Indeed, we don't care about gnuchess on Cortex-M, but the same issue affects building binutils, which may be a bit more important (for libbfd). Should we simply add a work-around in gnuchess, to build in -O0 for the time being ? Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes: Hi, > Therefore I guess the issue is in elf2flt, and I reported a bug at > https://github.com/uclinux-dev/elf2flt/issues/11. Thanks. > In the mean time, I'm not sure what to do. Indeed, we don't care about > gnuchess on Cortex-M, but the same issue affects building binutils, > which may be a bit more important (for libbfd). > Should we simply add a work-around in gnuchess, to build in -O0 for the > time being ? You mean for gnuchess AND for binutils? I guess so.
diff --git a/package/gnuchess/gnuchess.mk b/package/gnuchess/gnuchess.mk index 4d91706de4..1bbbeb4b1b 100644 --- a/package/gnuchess/gnuchess.mk +++ b/package/gnuchess/gnuchess.mk @@ -13,4 +13,8 @@ GNUCHESS_DEPENDENCIES = host-flex flex GNUCHESS_DEPENDENCIES += $(if $(BR2_PACKAGE_READLINE),readline) \ $(TARGET_NLS_DEPENDENCIES) +GNUCHESS_CONF_ENV = \ + CFLAGS="$(TARGET_CFLAGS) -fPIC" \ + CXXFLAGS="$(TARGET_CXXFLAGS) -fPIC" + $(eval $(autotools-package))
When building with -O2 (or -O3) on ARM cortex-M cpus, link fails on: /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/bin/arm-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wl,-elf2flt -static -Wl,-elf2flt -static -Wl,-elf2flt -static -o gnuchess main.o components.o frontend/libfrontend.a adapter/libadapter.a engine/libengine.a -lreadline -lncurses 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 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 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 ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context To fix this, pas -fPIC unconditionnally Fixes: - http://autobuild.buildroot.org/results/7918757b255ed41609609d2083c2d8904ff3136e Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- Changes v1 -> v2 (after review of Thomas Petazzoni): - Use -fPIC instead of replacing -O2/O3 by -Os package/gnuchess/gnuchess.mk | 4 ++++ 1 file changed, 4 insertions(+)