Skip to contentSkip to conversation

directfb.inc: force bfd linker for armv7a

PATCH In review Andre McCurdy 4 participants 11 messages Nov 17, 2015 – Nov 18, 2015

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 directfb.inc: force bfd linker for armv7a

Workaround for linker errors seen with armv7a + gold:

 | ../arm-rdk-linux-gnueabi-libtool  --tag=CC   --mode=link arm-rdk-linux-gnueabi-gcc  -march=armv7-a -mfloat-abi=hard -mtune=cortex-a15 --sysroot=.../build/tmp/sysroots/eos -I.../build/tmp/sysroots/eos/usr/include/freetype2 -I.../build/tmp/sysroots/eos/usr/include/libpng16 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-strict-aliasing -Werror-implicit-function-declaration -O3 -g2 -ffast-math -pipe -O2 -pipe -g -feliminate-unused-debug-types -D_GNU_SOURCE  -std=gnu99 -Werror-implicit-function-declaration  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o directfb-csource directfb-csource.o -lpng16 -ldl -lrt -lpthread
 | arm-rdk-linux-gnueabi-libtool: link: arm-rdk-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mtune=cortex-a15 --sysroot=.../build/tmp/sysroots/eos -I.../build/tmp/sysroots/eos/usr/include/freetype2 -I.../build/tmp/sysroots/eos/usr/include/libpng16 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-strict-aliasing -Werror-implicit-function-declaration -O3 -g2 -ffast-math -pipe -O2 -pipe -g -feliminate-unused-debug-types -D_GNU_SOURCE -std=gnu99 -Werror-implicit-function-declaration -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o directfb-csource directfb-csource.o  .../build/tmp/sysroots/eos/usr/lib/libpng16.so -lz -lm -ldl -lrt -lpthread
 | .../build/tmp/sysroots/x86_64-linux/usr/bin/arm-rdk-linux-gnueabi/../../libexec/arm-rdk-linux-gnueabi/gcc/arm-rdk-linux-gnueabi/5.2.0/ld: error: directfb-csource.o: requires unsupported dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
 | collect2: error: ld returned 1 exit status
---
 meta/recipes-graphics/directfb/directfb.inc | 3 +++
 1 file changed, 3 insertions(+)
meta/recipes-graphics/directfb/directfb.inc +3 -0
index 446aaea..cbd4014 100644
@@ -22,6 +22,9 @@ S = "${WORKDIR}/DirectFB-${PV}"
 
 LDFLAGS_append =" -lts -lm"
 
+# Workaround for linking issues seen with armv7a + gold
+LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is-gold', ' -fuse-ld=bfd ', '', d)}"
+
 BINCONFIG = "${bindir}/directfb-config"
 
 inherit autotools binconfig-disabled pkgconfig
Signature · 1 line
1.9.1
#1 lore raw
Quoted 5 lines · Andre McCurdy

|
.../build/tmp/sysroots/x86_64-linux/usr/bin/arm-rdk-linux-gnueabi/../../libexec/arm-rdk-linux-gnueabi/gcc/arm-rdk-linux-gnueabi/5.2.0/ld:
error: directfb-csource.o: requires unsupported dynamic reloc
R_ARM_MOVW_ABS_NC; recompile with -fPIC

Martin just sent a patch to pass -fPIC, presumably that is preferable to changing the linker?

Ross

#2 lore raw
In reply to Andre McCurdy
Quoted 1 line · Andre McCurdy

+# Workaround for linking issues seen with armv7a + gold

Review

Quoted 3 lines
(quoted diff) +1 -1
+LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is
-gold', ' -fuse-ld=bfd ', '', d)}"

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

p.

#3 lore raw
Quoted 4 lines · Phil Blundell

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Personally I don't use DirectFB (and am constantly surprised it's still a thing) so at this point I'm not going to merge either of these patches until someone can confirm that their fix *works on hardware* instead of just fixing the build.

Ross

#4 lore raw
Quoted 10 lines · Ross
Quoted 4 lines · Phil Blundell

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Personally I don't use DirectFB (and am constantly surprised it's still a thing) so at this point I'm not going to merge either of these patches until someone can confirm that their fix *works on hardware* instead of just fixing the build.

I think that's a reasonable position. In any case, the underlying issue is a compiler bug and ought really to be fixed there rather than patching directfb or any other package that just happens to fall over it.
p.

#5 lore raw
Quoted 15 lines · Phil Blundell

On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:

On 17 November 2015 at 15:16, Phil Blundell <[email protected]> wrote:

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Personally I don't use DirectFB (and am constantly surprised it's still a thing) so at this point I'm not going to merge either of these patches until someone can confirm that their fix *works on hardware* instead of just fixing the build.

Quoted 4 lines

I think that's a reasonable position. In any case, the underlying issue is a compiler bug and ought really to be fixed there rather than patching directfb or any other package that just happens to fall over it.

The directfb-csource binary linked with the bfd linker segfaults on startup, so it does indeed look like a compiler problem.

#6 lore raw
Quoted 16 lines · Andre McCurdy
Quoted 15 lines · Phil Blundell

On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:

On 17 November 2015 at 15:16, Phil Blundell <[email protected]> wrote:

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Personally I don't use DirectFB (and am constantly surprised it's still a thing) so at this point I'm not going to merge either of these patches until someone can confirm that their fix *works on hardware* instead of just fixing the build.

Quoted 7 lines
Quoted 4 lines

I think that's a reasonable position. In any case, the underlying issue is a compiler bug and ought really to be fixed there rather than patching directfb or any other package that just happens to fall over it.

The directfb-csource binary linked with the bfd linker segfaults on startup, so it does indeed look like a compiler problem.

Hmmm... maybe I spoke too soon. lsmod is also segfaulting on startup so there's something else going wrong with this build.

If I copy the same directfb-csource binary into a rootfs built with security_flags.inc enabled then it runs OK...

#7 lore raw
Quoted 19 lines · Andre McCurdy
Quoted 18 lines · Andre McCurdy
Quoted 16 lines · Phil Blundell

On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:

On 17 November 2015 at 15:16, Phil Blundell <[email protected]> wrote:

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Personally I don't use DirectFB (and am constantly surprised it's still a thing) so at this point I'm not going to merge either of these patches until someone can confirm that their fix *works on hardware* instead of just fixing the build.

I think that's a reasonable position. In any case, the underlying issue is a compiler bug and ought really to be fixed there rather than patching directfb or any other package that just happens to fall over it.

Quoted 8 lines
Quoted 2 lines

The directfb-csource binary linked with the bfd linker segfaults on startup, so it does indeed look like a compiler problem.

Hmmm... maybe I spoke too soon. lsmod is also segfaulting on startup so there's something else going wrong with this build.

If I copy the same directfb-csource binary into a rootfs built with security_flags.inc enabled then it runs OK...

OK, so the segfaults were due to building Jethro with prelink enabled :-(

With prelink disabled, directfb-csource linked with the bfd linker runs fine on real HW:

root@eos:~# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls
vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x42
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0x00f
CPU revision    : 3

processor : 1
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x42
CPU architecture: 7
CPU variant : 0x0
CPU part : 0x00f
CPU revision : 3

Hardware : Broadcom STB (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
root@eos:~#

root@eos:~# directfb-csource
directfb-csource version 1.7.7

Usage: directfb-csource [options] <imagefile>
--name=<identifer> specifies variable name
--format=<identifer> specifies surface format
--rgbformat=<identifer> specifies format for non-alpha images

   --multi                 multiple images
   --raw                   dump a single file directly to header
   --dither-rgb16          dither images rendered to RGB16 surfaces
   --help                  show this help message
   --version               print version information

See the directfb-csource(1) man-page for more information.

root@eos:~#

#8 lore raw
In reply to Phil Blundell
Quoted 18 lines · Phil Blundell
Quoted 11 lines · Ross
Quoted 5 lines · Phil Blundell

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Quoted 4 lines

Personally I don't use DirectFB (and am constantly surprised it's still a thing) so at this point I'm not going to merge either of these patches until someone can confirm that their fix *works on hardware* instead of just fixing the build.

Quoted 4 lines

I think that's a reasonable position. In any case, the underlying issue is a compiler bug and ought really to be fixed there rather than patching directfb or any other package that just happens to fall over it.

I had another look at this and my previous recollection was not quite right. What's happening here is that we have:

        movw    r1, #:lower16:longjmp
        mov     r2, #392
        movt    r1, #:upper16:longjmp
        bl      png_set_longjmp_fn

which is not an unreasonable thing for the compiler to generate in the circumstances and results in the assembler producing:

00000798  0000722b R_ARM_MOVW_ABS_NC 00000000   longjmp
000007a0  0000722c R_ARM_MOVT_ABS    00000000   longjmp

114: 00000000 0 NOTYPE GLOBAL DEFAULT UND longjmp

which is also fine. However gold is getting a bit mixed up and seems to be forgetting to generate a plt entry for longjmp. Instead it tries to produce:

0000a124  0000132b R_ARM_MOVW_ABS_NC 00000000   longjmp
0000a12c  0000132c R_ARM_MOVT_ABS    00000000   longjmp
    19: 00000000     0 FUNC    GLOBAL DEFAULT  UND longjmp@GLIBC_2.4 (4)
   104: 00000000     0 FUNC    GLOBAL DEFAULT  UND longjmp

which is bogus.

So, contrary to what I said before, I don't think gcc is doing anything wrong and it seems fairly clear that the bug is in gold. That being the case, I think switching to ld.bfd is a reasonable workaround. Adding -fPIC also works around the problem in a different way (it replaces the MOVx_ABS relocs with a load from the constant pool and a corresponding GLOB_DAT reloc) but this will produce worse code. So I would be inclined to merge Andre's patch. If someone wanted to distil a testcase from this and file a bug against gold upstream then that would be even better.

p.

#9 lore raw
In reply to Phil Blundell
Quoted 10 lines · Phil Blundell
Quoted 1 line · Andre McCurdy

+# Workaround for linking issues seen with armv7a + gold

Review

Quoted 3 lines
(quoted diff) +1 -1
+LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is
-gold', ' -fuse-ld=bfd ', '', d)}"

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

thats right. real problem here is that there is a static library generating with out pic options and being linked into shared object. gold is flagging it since it will fail at runtime. Please pass --enable-shared to configure that should help if that does not then pass -fPIC in CFLAGS

#10 lore raw
Quoted 12 lines · Khem Raj
Quoted 10 lines · Phil Blundell
Quoted 1 line · Andre McCurdy

+# Workaround for linking issues seen with armv7a + gold

Review

Quoted 3 lines
(quoted diff) +1 -1
+LDFLAGS_append_armv7a = "${@base_contains('DISTRO_FEATURES', 'ld-is
-gold', ' -fuse-ld=bfd ', '', d)}"

Does the resulting directfb-csource binary actually work with that change? My recollection is that ld.bfd will just silently permit relocs that gold (correctly) refuses to allow.

Quoted 5 lines

thats right. real problem here is that there is a static library generating with out pic options and being linked into shared object. gold is flagging it since it will fail at runtime. Please pass --enable-shared to configure that should help if that does not then pass -fPIC in CFLAGS

Note that directfb-csource is an application, not a shared library.

First directfb-csource.c is compiled to directfb-csource.o and then directfb-csource.o is linked with -lpng16 -ldl -lrt -lpthread to create the directfb-csource application. I don't see an obvious reason why -fPIC should be needed when directfb-csource.c is compiled?