[PATCH] directfb.inc: force bfd linker for armv7a

[PATCH] directfb.inc: force bfd linker for armv7a

[Andre McCurdy]

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

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/recipes-graphics/directfb/directfb.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-graphics/directfb/directfb.inc b/meta/recipes-graphics/directfb/directfb.inc
index 446aaea..cbd4014 100644
--- a/meta/recipes-graphics/directfb/directfb.inc
+++ b/meta/recipes-graphics/directfb/directfb.inc
@@ -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
-- 
1.9.1

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On 17 November 2015 at 05:56, Andre McCurdy <armccurdy@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 857 bytes --]

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Phil Blundell]

On Mon, 2015-11-16 at 21:56 -0800, Andre McCurdy wrote:
> 
+# Workaround for linking issues seen with armv7a + gold
> +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.

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On 17 November 2015 at 15:16, Phil Blundell <pb@pbcl.net> 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.

Ross

[-- Attachment #2: Type: text/html, Size: 922 bytes --]

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Phil Blundell]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:
> 
> On 17 November 2015 at 15:16, Phil Blundell <pb@pbcl.net> 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.
p.

[-- Attachment #2: Type: text/html, Size: 1178 bytes --]

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Andre McCurdy]

On Tue, Nov 17, 2015 at 9:09 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:
>
> On 17 November 2015 at 15:16, Phil Blundell <pb@pbcl.net> 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.
>

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

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Khem Raj]

On Tue, Nov 17, 2015 at 7:16 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Mon, 2015-11-16 at 21:56 -0800, Andre McCurdy wrote:
>>
> +# Workaround for linking issues seen with armv7a + gold
>> +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

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Andre McCurdy]

On Tue, Nov 17, 2015 at 11:16 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Tue, Nov 17, 2015 at 9:09 AM, Phil Blundell <pb@pbcl.net> wrote:
>> On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:
>>
>> On 17 November 2015 at 15:16, Phil Blundell <pb@pbcl.net> 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.
>>
>
> 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...

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Andre McCurdy]

On Tue, Nov 17, 2015 at 11:33 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Nov 17, 2015 at 7:16 AM, Phil Blundell <pb@pbcl.net> wrote:
>> On Mon, 2015-11-16 at 21:56 -0800, Andre McCurdy wrote:
>>>
>> +# Workaround for linking issues seen with armv7a + gold
>>> +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

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?

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Andre McCurdy]

On Tue, Nov 17, 2015 at 11:34 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Tue, Nov 17, 2015 at 11:16 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Tue, Nov 17, 2015 at 9:09 AM, Phil Blundell <pb@pbcl.net> wrote:
>>> On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:
>>>
>>> On 17 November 2015 at 15:16, Phil Blundell <pb@pbcl.net> 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.
>>
>> 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:~#

Re: [PATCH] directfb.inc: force bfd linker for armv7a

[Phil Blundell]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

On Tue, 2015-11-17 at 17:09 +0000, Phil Blundell wrote:
> On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:
> > 
> > 
> > On 17 November 2015 at 15:16, Phil Blundell <pb@pbcl.net> 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.

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.


[-- Attachment #2: Type: text/html, Size: 4076 bytes --]