ld: Clarify --wrap documentation

Message ID 20190110141146.1781-1-sebastian.huber@embedded-brains.de
State New
Headers show
Series
  • ld: Clarify --wrap documentation
Related show

Commit Message

Sebastian Huber Jan. 10, 2019, 2:11 p.m.
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(+)

-- 
2.16.4

Comments

Hans-Peter Nilsson Jan. 10, 2019, 8:16 p.m. | #1
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"?

> +

> +@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 Jan. 10, 2019, 9:48 p.m. | #2
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
Sebastian Huber Jan. 11, 2019, 7:15 p.m. | #3
----- 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?
Alan Modra Jan. 11, 2019, 10:37 p.m. | #4
On Fri, Jan 11, 2019 at 08:15:33PM +0100, Sebastian Huber wrote:
> Ok, what about "translation unit"?


Even better.

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


I haven't looked into that, sorry.

-- 
Alan Modra
Australia Development Lab, IBM
Cary Coutant Jan. 15, 2019, 11:24 p.m. | #5
> > What is the effect of LTO with respect to the wrapping?

>

> I haven't looked into that, sorry.


It's not (yet?) supported. See PR lto/88643 in GCC bugzilla:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

-cary

Patch

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}.
+
+@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