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

[Alan Modra <amodra at gmail dot com>]

On Mon, Jan 28, 2019 at 10:28:24AM +0100, Sebastian Huber wrote:
> On 26/01/2019 00:52, Alan Modra wrote:
> > On Fri, Jan 25, 2019 at 02:55:35PM +0100, Sebastian Huber wrote:
> > > @@ -2780,6 +2780,8 @@ extern asection _bfd_elf_large_com_section;
> > >   	return FALSE;							\
> > >   									\
> > >         h = sym_hashes[r_symndx - symtab_hdr->sh_info];			\
> > Is it possible to arrange for the symbol hashes to be set up to point
> > to the wrapped symbols?  I'm thinking a change to always use
> > bfd_wrapped_link_hash_lookup in _bfd_generic_link_add_one_symbol might
> > work.
> 
> Is this hash table only used for the relocations? We need mappings for

No.  There are other uses.

> This leads to multiple definition errors and unresolved references:
> 
> build/ld/ld-new: main2.o: in function `__wrap_f':
> main2.c:(.text+0x11): multiple definition of `__wrap_f';
> main2.o:main2.c:(.text+0x0): first defined here

Ah yes, I forgot the obvious.  _bfd_generic_link_add_one_symbol itself
uses the symbol hash.  OK, so always substituting in
_bfd_generic_link_add_one_symbol may not be a good idea.

> I don't know why there is a special case for debug sections in
> RELOC_FOR_GLOBAL_SYMBOL():

In general, debug info is describing the local function in an object
file, not some other function.  See commit 8a5da09b9e log:

    Unwrap symbols for debug information
    
    Fixes issues with dwz multi-file (-m) and ld's -wrap option.
    Symbols referenced from DWARF debug info in a separate file, eg. to
    specify low and high pc, must use the real symbol.  The DWARF info
    is specifying attributes of the real function, not one interposed
    with --wrap.

> 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..

-- 
Alan Modra
Australia Development Lab, IBM