Re: [rfc] Fix mst_solib_trampoline symbol sections for PLT stubs

[Daniel Jacobowitz <drow@false.org>]

On Wed, Oct 31, 2007 at 02:36:39AM +0100, Ulrich Weigand wrote:
> Hello,
> 
> we're still seeing problems on ppc when stepping over shared library
> function calls, due to the issue previously discussed e.g. in:
> http://sourceware.org/ml/gdb-patches/2006-06/msg00368.html
> 
> Now, at the time the discussion primarily focussed on ways how to
> identify PLT stubs via e.g. code reading or BFD synthetic symbols.

Which are otherwise useful too; I really recommend making a synthetic
symtab.  I thought PowerPC BFD already did... oh, 64-bit only.  Right.

> Now, for undefined symbols, the "value" is generally meaningless.
> However, in this specific case, the linker actually may place a
> significant piece of information into the value field: the address
> of the PLT stub used to call the imported function.
> 
> It is my understanding that this information is generally reliable,
> as it is implemented e.g. to determine the value of a function
> pointer constant refering to that symbol (due to the special ABI
> rule that the "address" of a function imported into the main 
> executable, for function pointer comparison purpuses, is the
> address of the PLT stub in the main executable).

Yes.  But if the address of the function is not taken somewhere in the
executable, then the address of the undefined symbol will generally be
left at zero.  That should be true most of the time.  So while I don't
see anything wrong with your approach here, I'm surprised it fixed the
testsuite failures; why do they have non-zero addresses?  If we're
taking their addresses in all cases, we need some new tests.

The patch itself looks fine.

-- 
Daniel Jacobowitz
CodeSourcery