Re: IFUNC resolver scheduling (bugs 21041, 20019)

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 25/01/17 13:57, Florian Weimer wrote:
> One problem is that recording the relocations requires temporary memory allocations during relocation.  I have
> a mmap-based pool allocator for that (currently very specific to the task at hand, but I will have to
> generalize it a bit).  The allocations are required so that we do not have to walk through large parts of the
> relocation list in the second pass.  The number of delayed relocations is significant: around 100 for simple
> binaries, and more than 1,000 for complex ones.  The current delayed relocation record contains six words, so
> we are talking about several KiB even for small binaries.  I'm not convinced it makes sense to add a large
> static stack allocation (like scratch_buffer does) to avoid calling mmap because the stack memory remains dirty
> and might not be reused by some programs.  Adding at least one mmap and munmap call to the start-up sequence is
> likely visible in benchmarks, though.

why is it bad to walk over the relocation list again
in the second pass? (sounds simpler than the allocation)

if the first relocation that needs to be delayed is
recorded then the second pass can start from that point,
so if a dso has no ifunc related relocs it would not
be penalized by the second pass at all.

> Apart from the performance impact and complexity, there is another issue I worry about: What happens if an
> IFUNC-based relocation is subject to a copy relocation?  Assuming we delay IFUNC relocations and copy
> relocations and execute them in that order, the data produced by the copy relocation is correct because the
> IFUNC relocation has been performed before the copy is made.  But what happens if the copy-relocated symbol is
> accessed by the IFUNC resolver?  I think it will touch the object at its final location, and that has not been
> relocated yet.  I suppose this is similar to the dependency bypass due to function interposition.  Maybe it's
> sufficient to document this; it is certainly easier to avoid than the current restriction on accessing *any*
> relocated data.  This looks like a circular dependency which is impossible to resolve in general (and rather
> expensive to detect).

if by 'ifunc-based' relocation you mean that the
copy relocation refers to an STT_GNU_IFUNC type
symbol, then that should not happen and it is ok
to crash on it.

i still think that it is invalid for an ifunc resolver
to return an object address but in case of copy relocs
it would not work anyway:

to do the copy the symbol size in the symbol table is
used but that's the size of the resolver function, not
the size of the object whose address is returned.