[PATCH] ld: Clarify --wrap documentation

[Sebastian Huber]

----- Am 10. Jan 2019 um 22:48 schrieb Alan Modra amodra@gmail.com:

> On Thu, Jan 10, 2019 at 03:16:08PM -0500, Hans-Peter Nilsson wrote:
>> On Thu, 10 Jan 2019, Sebastian Huber wrote:
>> 
>> > ld/
>> > 	ld.texi (--wrap): Add example to emphasise that only undefined
>> > 	references are replaced by the linker
>> > ---
>> >  ld/ld.texi | 19 +++++++++++++++++++
>> >  1 file changed, 19 insertions(+)
>> >
>> > diff --git a/ld/ld.texi b/ld/ld.texi
>> > index cc0d220fa0..03c5581a3b 100644
>> > --- a/ld/ld.texi
>> > +++ b/ld/ld.texi
>> > @@ -2392,6 +2392,25 @@ you should not put the definition of @code{__real_malloc}
>> > in the same
>> >  file as @code{__wrap_malloc}; if you do, the assembler may resolve the
>> >  call before the linker has a chance to wrap it to @code{malloc}.
>> >
>> > +Only undefined references are replaced by the linker.  So, module internal
>> > +references to @var{symbol} are not resolved to @code{__wrap_@var{symbol}}.  In
>> > +the next example, the call to @code{f} in @code{g} is not resolved to
>> > +@code{__wrap_f}.
>> 
>> The "is not" is too affirmative: what happens depends on the
>> target and compiler options.  Perhaps "may or may not be"?
> 
> That is technically true, but typically doesn't happen in practice.
> You'd need a compiler/assembler combination that emitted *two* symbols
> for "f" (of the same name) in the object file, one used by relocations
> referencing "f", the other by the definition.  "is not" is fine, I
> think.
> 
> OK with "module" replaced by "compilation module".

Ok, what about "translation unit"?

What is the effect of LTO with respect to the wrapping?