man3/dlopen.3: Describe confusing dladdr() behavior

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

int
main(void)

{
	void *func;
	Dl_info info = {};

	func = printf;
	dladdr(func, &info);
	printf("%s at %p resolved from %s\n", info.dli_sname,
			func, info.dli_fname);

	return 0;
}

dladdr() will act unexpectedly if called from non-pic code on a compile-time-generated function pointer:

Quoted 17 lines

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

int
main(void)

{
      void *func;
      Dl_info info = {};

      func = printf;
      dladdr(func, &info);
      printf("%s at %p resolved from %s\n", info.dli_sname,
                      func, info.dli_fname);

      return 0;

In the long term, it might make sense to make dladdr() recognize plt pointers and recurse, but I'm too afraid of Ulrich ;-) (and he seems to be heavy proponent of pic code anyway, so the chances for that to be accepted probably aren't high).

Signed-off-by Petr Baudis <[email protected]>

man3/dlopen.3 +2 -1

index d302360..649c449 100644
@@ -30,8 +30,9 @@
 .\" Modified by Matt Domsch, 2003-04-09: _init and _fini obsolete
 .\" Modified by Michael Kerrisk <[email protected]> 2003-05-16.
 .\" Modified by Walter Harms: dladdr, dlvsym
+.\" Modified by Petr Baudis <[email protected]>, 2008-12-04: dladdr caveat
 .\"
-.TH DLOPEN 3 2008-10-27 "Linux" "Linux Programmer's Manual"
+.TH DLOPEN 3 2008-12-04 "Linux" "Linux Programmer's Manual"
 .SH NAME
 dladdr, dlclose, dlerror, dlopen, dlsym, dlvsym \- programming interface to
 dynamic linking loader

then, the compiler cannot prepare the pointer
+at the compile time anymore and today's gcc will just load

+the final symbol address from the
+.I GOT

man3/dlopen.3 That system also has

Quoted 4 lines · Petr Baudis

man3/dlopen.3 +4 -0

+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

Quoted 2 lines

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.

man3/dlopen.3 +7 -0

@@ -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

man3/dlopen.3 +1 -0

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

Hi!

Quoted 7 lines · Michael Kerrisk

Review

Quoted 4 lines · Petr Baudis

(quoted diff) +4 -0

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

Quoted 6 lines

Quoted 2 lines

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.)

Quoted 16 lines · Michael Kerrisk

(quoted diff) +12 -0

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

Review That system also has · line 434

Quoted 5 lines

(quoted diff) +5 -0

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

Quoted 5 lines

(quoted diff) +5 -0

+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

Review That system also has · line 444

Quoted 5 lines

(quoted diff) +5 -0

+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).

Review That system also has · line 448

Quoted 4 lines

(quoted diff) +1 -0

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