[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Fabrice Fontaine]

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(+)

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

[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Arnout Vandecappelle]

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

[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Peter Korsgaard]

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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Thomas Petazzoni]

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 Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC

[Peter Korsgaard]

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

-- 
Bye, Peter Korsgaard