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

[Phil Blundell <pb@pbcl.net>]

[-- 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 --]