Re: dladdr(): adventure in ABIs, function descriptors in IA-64 and HPPA vs PPC64 ELFv1

[Yann Droneaud <ydroneaud at opteya dot com>]

Hi,

Le lundi 24 juin 2019 à 19:47 -0400, Carlos O'Donell a écrit :
> On 6/24/19 1:36 PM, Yann Droneaud wrote:
> > 
> > In https://sourceware.org/bugzilla/show_bug.cgi?id=24561, I've
> > summarized my discoveries regarding dladdr() implementation(s).
> > 
> > I've managed to make dladdr() works faster for generic ELF and PPC
> > 64bits ELFv1.
> > 
> > I would like to contribute some tests for dladdr() to prove the
> > optimisations produce the same results as current implementation.
> > 
> > Before doing so, I have to understand interaction between dladdr() and
> > IA-64  and PA-Risc function descriptors.
> > 
> > ppc64 ELFv1 was quite simple to handle with regard to function
> > descriptors (but required increasing the memory needed for the symbols
> > cache).
> > 
> > But the two others set ELF_FUNCTION_PTR_IS_SPECIAL and rely on dl-fptr, 
> > which I haven't look to much, but seem definitely less straightforward.
> > As there's some linear search through a linked list, it might be useful
> > I look at it.
> > 
> > Could someone comment why function descriptors support is so different
> > between ppc64 and the other, one not using ELF_FUNCTION_PTR_IS_SPECIAL
> > and the others using it ?
> 
> Andreas Schwab already commented on the bugzilla, but I'll comment here
> for reference.

Thanks to you both !

> On ppc64 the function descriptors are in a statically allocated section
> that is setup by the static linker.
> 
> On ia64 and hppa the descriptors are allocated dynamically at runtime.
> 

Thanks.

>  
> > Unfortunately digging through the git history and looking at commit
> > messages and ChangeLog was not really useful, as those at mostly being
> > "captain-obvious" style descriptions of the changes, without any
> > explanation, motivation, rationale for the (added) changes.
> 
> The git history, even a detailed one, would never explain all the nuances
> of a particular ABI and the historical implementation choices.
> 

Sure, but git commit message should now be the place to start
explaining those choices in order to capture some of the nuances that
are considered at the time they're made.

> The history is that the 32-bit hppa runtime had direct functions (low bit-2
> not set) and function descriptors (low bit-2 set), and so you don't always
> use a function descriptor. HJ Lu moved ia64 over to a new harmonized descriptor
> list handling code, and likewise I ported hppa to the same routines, but then
> had to clone them to make significant changes.
> 
> If you have any direct questions, please just ask. In theory I still am
> the hppa maintainer, and I worked on the function pointer implementation
> for hppa.
> 

I've made some tests on PA-RISC (through QEMU user mode emulation) and
experienced what I've feared: a very different behavior between ABIs.

Unlike with PowerPC 64 bits ELFv1 ABI where function descriptor and
function implementation lead to the same symbol, it seems on HPPA,
dladdr(dlsym(RTLD_DEFAULT, "symbol"), &info) doesn't return a matching
symbol: info.dli_sname and info.dli_saddr are both NULL.

Having dladdr() being unable to match a pointer to a function
descriptor to its symbol name and address is a pity.

That makes creating a test case for my changes a bit more challenging.

Anyway dladdr() works for an address in the function, so backtraces can
be generated, that's probably the only use case that matter ?

What do you think ? Should I open a bug for that ?

Regards.

-- 
Yann Droneaud
OPTEYA