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

[John David Anglin <dave dot anglin at bell dot net>]

In looking at a problem in firebird3.0, I wrote:

> A binary nmu was done for firebird3.0 but it needs a patch to build.  See:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858868
>
> On hppa, dlsym returns a function pointer when passed the name of a function
> symbol.  It doesn't return the address of the function.  Thus, dladdr doesn't
> work.  To get the address of the function, one needs to call
> __canonicalize_funcptr_for_compare() with the pointer returned by dlsym.
>
> I think this problem exists in some other packages.  It is mentioned in the man
> page for dladdr (BUGS).
>
Dave

On 2019-06-26 5:23 p.m., Carlos O'Donell wrote:
> On 6/26/19 1:39 PM, Yann Droneaud wrote:
>> 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.
> This should have worked.
>
> dladdr -> DL_LOOKUP_ADDRESS -> fptr -> target ip of the descriptor.
>  
> The relevant resolution routine is sysdeps/hppa/dl-fptr.c (_dl_lookup_address).
>
> If that isn't being triggered then there is a bug.
>
>> Having dladdr() being unable to match a pointer to a function
>> descriptor to its symbol name and address is a pity.
> It should work.
>
>> 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 ?
> Please open a bug if there isn't one open already.
>
> I'm about a month away from having my hppa box back online, and you really
> need a real box to debug this. I'm surprised qemu is working for you :-)
>
> Dave,
>
> Do you have a box I can ssh to and borrow to test this?
>


-- 
John David Anglin  dave.anglin@bell.net