[Bug ld/14464] New: problem with script file on ppc64 elf

[ariel.burton at roguewave dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14464

             Bug #: 14464
           Summary: problem with script file on ppc64 elf
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: address@hidden
        ReportedBy: address@hidden
    Classification: Unclassified


Created attachment 6577
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6577
reproducer for the problem

The linker is not doing the its magic to fix up
function calls in all circumstances.  The reproducer
shown below use a script file create an alias to
a existing function.  Instead of fixing the target of
the branch to be the address in the opd entry, the
linker is branching to the opd itself.

Amongst the files included in the attached tar file are
are the following:

/* t_main.c */

#include  <stdio.h>

extern void x (void);
extern void y (void);

int
main ( int argc, char *argv [] )
{
  setvbuf ( stdout, 0, _IONBF, 0 );

  printf ( "about to call x\n" );
  x ();

  printf ( "about to call y\n" );
  y ();

  return 0;
}

/* x.c */

#include  <stdio.h>

void
x (void)
{
  printf ( "  in x\n" );
}

/* y.ldscript */

SECTIONS
{
  .opd : { y = x ; }
}

Build the test program by invoking make.

gcc -g -m64   -c -o t_main.o t_main.c
gcc -g -m64   -c -o x.o x.c
gcc -m64  t_main.o x.o y.ldscript   -o t_main

This is output from objdump -d of the final executable
t_main.  It shows how the direct call to the alias y
is handled differently from the direct call to x.
The code below was emitted by compiling with gcc 4.1.2 on
linux power ppc64 on SUSE ES 10, as follows:

    .
    .
    100006c0:   48 00 00 45     bl      10000704 <.x>
    100006c4:   60 00 00 00     nop
    100006c8:   e8 62 80 48     ld      r3,-32696(r2)
    100006cc:   4b ff fe 0d     bl      100004d8 <._init+0x70>
    100006d0:   e8 41 00 28     ld      r2,40(r1)
    100006d4:   48 01 05 75     bl      10010c48 <x>
    100006d8:   60 00 00 00     nop
    .
    .

Note the linker is not doing its magic to fix up the
call to go to the address in the opd, rather than branching
to the opd itself.

This is from the address@hidden mailing list
on 2012 08 11 (http://sourceware.org/ml/binutils/2012-08/msg00198.html):

On Fri, Aug 10, 2012 at 05:42:09PM -0400:
> In the case of the first call (the explicit call to x)
> the linker has adjusted the call address to call the
> function's entry point which it obtains from the opd of
> that name.  That is, it recognizes that the reference
> to x is a reference to the opd entry, and instead of
> branching to the opd it branches to the entry address
> given in the opd.  However, it's not doing the same
> with the call to y.  There it's treating the synthesized
> reference to x differently, and branching to the opd
> rather than the entry address given in the opd.

The reason this is failing is that all symbols defined in a linker
script are defined in output sections or the absolute section.  ppc64
ld does its magic with .opd only on symbols defined in *input* .opd
sections.  I don't know a work-around, sorry.  Please open a bug
report.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.