Odd code generated by binutils assembler for x86

Teemu Torma teemu@torma.org
Mon Mar 25 16:15:00 GMT 2002


On Tue, 2002-03-26 at 00:27, H . J . Lu wrote:
> The problem is gcc emits:
> 
>         .section        .gnu.linkonce.t._._9ft_ID_Key,"ax",@progbits
>         .align 16
> .LPR0:
>         movl    (%esp), %ebx
>         ret
>         .weak   _._9ft_ID_Key
>         .type    _._9ft_ID_Key,@function
> _._9ft_ID_Key:
> .LFB1:
>         pushl   %ebp
> .LCFI0:
>         movl    %esp, %ebp
> .LCFI1:
>         pushl   %edi
> .LCFI2:
>         pushl   %esi
> .LCFI3:
>         pushl   %ebx
> .LCFI4:
>         subl    $20, %esp
> .LCFI5:
>         call    .LPR0
> ...
>         .section        .gnu.linkonce.t.__tf9ft_ID_Key,"ax",@progbits
>         .align 16
>         .weak   __tf9ft_ID_Key
>         .type    __tf9ft_ID_Key,@function
> __tf9ft_ID_Key:  
> .LFB2:
>         pushl   %ebp
> .LCFI7:
>         movl    %esp, %ebp
> .LCFI8:
>         pushl   %esi
> .LCFI9:
>         pushl   %ebx
> .LCFI10:
>         call    .LPR0
> 
> That is instead of generating
> 
> .LPR0:
>         movl    (%esp), %ebx
>         ret
> 
> for each function in the linkonce section, gcc uses one
> 
> .LPR0:
>         movl    (%esp), %ebx
>         ret
> 
> in a linkonce section for the whole file. But the linker may discard
> that linkonce section where the .LPR0 code is in in the final binary.
> As the result, the current link will complain
> 
>         call    .LPR0
> 
> with something like
> 
> warning: relocation against removed section ...
> 
> and keep going. They will be turned into something like "call 0". Most
> of time, it is ok. But in your case, it is not. Personally, I believe
> it is a gcc bug.
> 
> Alan, should we make it a fatal error instead of just a warning? I
> don't believe it is safe at all now.
> 
> Teemu, could you please file a gcc bug report with your testcase?

Since it is 2.96-something problem as shipped with Mandrake 8.2, there
is no point making gcc bug report.  And for me there is easy workaround
to compile for i586 instead of i686.  I have not seen this with 2.95.x
nor with 3.0.x, but the generated code is different in each case.

But like I mentioned earlier, I fear it is an assembler bug, since the
problem can be seen _before_ linking in the object file, and only in one
object file out of many of them, and the rest of the system does work,
at least when linked with binutils as shipped by Mandrake. I did not try
the linking with the latest binutils, just the assembler part, and the
resulting object file showed the same problem.

I am just trying to make sure this is not a bug in binutils, that might
bite in another time in another place.

Teemu




More information about the Binutils mailing list