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.