Re: [PATCH] man3/dlopen.3: Describe confusing dladdr() behavior

[Petr Baudis <pasky-AlSwsSmVLrQ@public.gmane.org>]

Hi!

On Fri, Dec 05, 2008 at 05:50:25PM -0500, Michael Kerrisk wrote:
> On Thu, Dec 4, 2008 at 9:44 PM, Petr Baudis <pasky-AlSwsSmVLrQ@public.gmane.org> wrote:
> > +section of the original object (which dispatches the call after
> > +asking the dynamic linker to resolve the symbol).
> > +To work this around, you can try to compile the code to be
> > +position-independent:
> 
> I added: "gcc -fPIC" here

Sometimes, -fpic might be better idea, for executables -fpie or -fPIE is
better choice, which is why I chose not to mention a particular switch.
It should be easy to look that up in the gcc manual page and you should
understand the implications of this choice before doing it anyway.

> > then, the compiler cannot prepare the pointer
> > +at the compile time anymore and today's gcc will just load
> 
> I made it "gcc(1)", but this doesn't seem quite right.  It's not gcc
> in operation at program run time.  can you more precisely say what you
> mean here.

What about "code generated by today's gcc"? (I don't know if gcc always
behaved like that or what do other compilers do, and I'm not willing to
do the research in this case.)

On Fri, Dec 05, 2008 at 05:55:28PM -0500, Michael Kerrisk wrote:
> @@ -414,6 +415,34 @@ That system also has
>  .BR dladdr (),
>  but not
>  .BR dlvsym ().
> +.SH BUGS
> +Sometimes, the function pointers you pass to
> +.BR dladdr ()
> +may surprise you.
> +On some architectures (notably i386 and x86_64),
> +.I dli_fname
> +and
> +.I dli_fbase
> +may end up pointing back at the object from which you called
> +.BR dladdr (),
> +even if the function used as an argument should come from
> +a dynamically linked library.
> +.PP
> +The problem is that the function pointer will still be resolved
> +at compile time, but merely point to the
> +.I plt
> +(procedure linkage table)

The section name is "plt" but the expanded name should be capitalized,
while...

> +section of the original object (which dispatches the call after
> +asking the dynamic linker to resolve the symbol).
> +To work this around, you can try to compile the code to be
> +position-independent
> +.RI ( "cc -fPIC" ): then, the compiler cannot prepare the pointer
> +at compile time anymore and today's
> +.BR gcc (1)
> +will just load the final symbol address from the
> +.I GOT
> +(Global Offset Table) at run time before passing it to

...here I guess either the acronym is not necessary or it should be
"got" for consistency (the section name).

> +.BR dladdr ().
>  .SH EXAMPLE
>  Load the math library, and print the cosine of 2.0:
>  .nf

-- 
				Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html