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 <p...@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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
