ppc 32/64 elf script question

[ariel dot burton at roguewave dot com]

I'd appreciate some help with the following.

For reasons that I won't go into here I need to check
at link time whether a particular function is present,
and if it is not, create an alias with that name to
another function.  I can't use weak definitions or
aliases at the source / object file level.

On ppc32 elf (linux) I'm able to construct a script file
which can be listed on the command line along with ordianry
object files and library archives.  This script file reads
something like this:

  SECTIONS
  {
    .text : {
      y = DEFINED ( y ) ? y : x ;
    }
  }

The intention here is that if a function y is defined, calls
to y will be bound to y.  Otherwise, if y is not defined,
calls to it will be bound to x.  x and y have the same prototypes.

This appears to work as I expect on 32-bit power lunux elf.

I am trying to use the same sort of approach for the 64-bit
case, but am having trouble.  As the ABI is different,
what I do is this:

  SECTIONS
  {
    .opd : {
      y = DEFINED ( y ) ? y : x ;
    }
  }

This should map y to x's opd entry.

I have some C code in main.c which makes calls to x and y:

  x ();
  .
  .
  y ();

x is defined in x.c.  The assembler generated by the compiler
for this file defines an opd entry for x with label x.
The entry point of the function is called .L.x, and appears
in the opd entry.

This is what the assembly the the compiler (gcc) emits for
the calls in main.c:

        bl x
        nop
        .
        .
        bl y
        nop

I understand the purpose of the `nop' place holders.

However, after linking the .o for this file with the script
I see that the code generated is:

    10000814:   48 00 00 45     bl      10000858 <.x>
    10000818:   60 00 00 00     nop
    .
    .
    10000828:   48 01 0a 79     bl      100112a0 <x>
    1000082c:   60 00 00 00     nop
 
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.

How can I make the linker treat the two references
in the same way?

Thanks,

Ariel Burton