Re: [PATCH] ld: Clarify --wrap documentation

[Alan Modra <amodra at gmail dot 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".

> > +
> > +@smallexample
> > +int
> > +f (void)
> > +@{
> > +  return 123;
> > +@}
> > +
> > +int
> > +g (void)
> > +@{
> > +  return f();
> > +@}
> > +@end smallexample
> > +
> >  @kindex --eh-frame-hdr
> >  @kindex --no-eh-frame-hdr
> >  @item --eh-frame-hdr
> > --
> > 2.16.4
> >
> 
> brgds, H-P

-- 
Alan Modra
Australia Development Lab, IBM