<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5">
</HEAD>
<BODY>
On Tue, 2015-11-17 at 17:09 +0000, Phil Blundell wrote:
<BLOCKQUOTE TYPE=CITE>
    On Tue, 2015-11-17 at 16:44 +0000, Burton, Ross wrote:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE TYPE=CITE>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE TYPE=CITE>
        On 17 November 2015 at 15:16, Phil Blundell &lt;<A HREF="mailto:pb@pbcl.net">pb@pbcl.net</A>&gt; wrote:
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE TYPE=CITE>
        <BLOCKQUOTE TYPE=CITE>
            Does the resulting directfb-csource binary actually work with that<BR>
            change?&nbsp; My recollection is that ld.bfd will just silently permit<BR>
            relocs that gold (correctly) refuses to allow.
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE TYPE=CITE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE TYPE=CITE>
        <BR>
        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.
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    I think that's a reasonable position. &nbsp;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.
</BLOCKQUOTE>
<BR>
I had another look at this and my previous recollection was not quite right.&nbsp; What's happening here is that we have:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; movw&nbsp;&nbsp;&nbsp; r1, #:lower16:longjmp<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mov&nbsp;&nbsp;&nbsp;&nbsp; r2, #392<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; movt&nbsp;&nbsp;&nbsp; r1, #:upper16:longjmp<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; png_set_longjmp_fn<BR>
<BR>
which is not an unreasonable thing for the compiler to generate in the circumstances and results in the assembler producing:<BR>
<BR>
00000798&nbsp; 0000722b R_ARM_MOVW_ABS_NC 00000000&nbsp;&nbsp; longjmp<BR>
000007a0&nbsp; 0000722c R_ARM_MOVT_ABS&nbsp;&nbsp;&nbsp; 00000000&nbsp;&nbsp; longjmp<BR>
<BR>
&nbsp;&nbsp; 114: 00000000&nbsp;&nbsp;&nbsp;&nbsp; 0 NOTYPE&nbsp; GLOBAL DEFAULT&nbsp; UND longjmp<BR>
<BR>
which is also fine.&nbsp; However gold is getting a bit mixed up and seems to be forgetting to generate a plt entry for longjmp.&nbsp; Instead it tries to produce:<BR>
<BR>
0000a124&nbsp; 0000132b R_ARM_MOVW_ABS_NC 00000000&nbsp;&nbsp; longjmp<BR>
0000a12c&nbsp; 0000132c R_ARM_MOVT_ABS&nbsp;&nbsp;&nbsp; 00000000&nbsp;&nbsp; longjmp<BR>
<BR>
&nbsp;&nbsp;&nbsp; 19: 00000000&nbsp;&nbsp;&nbsp;&nbsp; 0 FUNC&nbsp;&nbsp;&nbsp; GLOBAL DEFAULT&nbsp; UND longjmp@GLIBC_2.4 (4)<BR>
&nbsp;&nbsp; 104: 00000000&nbsp;&nbsp;&nbsp;&nbsp; 0 FUNC&nbsp;&nbsp;&nbsp; GLOBAL DEFAULT&nbsp; UND longjmp<BR>
<BR>
which is bogus.<BR>
<BR>
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.&nbsp; That being the case, I think switching to ld.bfd is a reasonable workaround.&nbsp; 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.&nbsp; So I would be inclined to merge Andre's patch.&nbsp; If someone wanted to distil a testcase from this and file a bug against gold upstream then that would be even better.<BR>
<BR>
p.<BR>
<BR>
</BODY>
</HTML>