Does the LD --wrap feature work for library internal references?

[Sebastian Huber]

On 29/01/2019 01:31, Alan Modra wrote:
>> Attached is a second version which does the wrapping in
>> RELOC_FOR_GLOBAL_SYMBOL(). It removes bfd_wrapped_link_hash_lookup(). I am
>> not sure if this is a good idea. This function is used in various places.
>> Maybe the wrapping needs to be done on other spots and not only in
>> RELOC_FOR_GLOBAL_SYMBOL().
> Yes, wrapping should happen for more than just relocs.  For instance,
> if a shared library references malloc and you're building an
> executable wih --wrap=malloc and have a __wrap_malloc, then I think
> the shared library reference ought to be satisfied by your
> __wrap_malloc.  That has implications for ELF symbol merging.  Note
> that I'm not even sure whether this works currently, but it is
> feasible that a shared library reference to malloc be satisfied by
> your __wrap_malloc while your __real_malloc results in
> malloc@@GLIBC_2.2.5  say.  If that does work currently we wouldn't want
> to break it..

Yes, there are LD testsuite failures with this patch exactly in this 
area. If I keep the symbol wrapping as is and in addition add it to 
RELOC_FOR_GLOBAL_SYMBOL(), then there is the problem that the __real_SYM 
-> SYM information was lost and we wrap SYM always to __wrap_SYM. This 
leads to an infinite recursion in:

void __wrap_f(void)
{
     __real_f();
}

Looks like no matter how I try it, it almost works. There are probably 
some reasons why it wasn't added for defined references in the last 20 
years.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.