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: unassig...@sourceware.org
ReportedBy: ariel.bur...@roguewave.com
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
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
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:
.
.
16c0: 48 00 00 45 bl 1704 <.x>
16c4: 60 00 00 00 nop
16c8: e8 62 80 48 ld r3,-32696(r2)
16cc: 4b ff fe 0d bl 14d8 <._init+0x70>
16d0: e8 41 00 28 ld r2,40(r1)
16d4: 48 01 05 75 bl 10010c48
16d8: 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 binut...@sourceware.org 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.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
