Hi Petr, Thanks for checking the patch. On Sat, Dec 6, 2008 at 5:01 AM, Petr Baudis <pasky@xxxxxxx> wrote: > 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@xxxxxxx> 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. Fair enough. I removed "gcc -fPIC". >> > 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"? Yep, i made it something like that. > (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... Done. >> +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). Done. >> +.BR dladdr (). >> .SH EXAMPLE >> Load the math library, and print the cosine of 2.0: >> .nf Below is the change for man-pages-3.16. Cheers, Michael --- a/man3/dlopen.3 +++ b/man3/dlopen.3 @@ -32,7 +32,7 @@ .\" Modified by Walter Harms: dladdr, dlvsym .\" Modified by Petr Baudis <pasky@xxxxxxx>, 2008-12-04: dladdr caveat .\" -.TH DLOPEN 3 2008-12-05 "Linux" "Linux Programmer's Manual" +.TH DLOPEN 3 2008-12-06 "Linux" "Linux Programmer's Manual" .SH NAME dladdr, dlclose, dlerror, dlopen, dlsym, dlvsym \- programming interface to dynamic linking loader @@ -431,17 +431,16 @@ a dynamically linked library. The problem is that the function pointer will still be resolved at compile time, but merely point to the .I plt -(procedure linkage table) +(Procedure Linkage Table) 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" ): +To work around this, +you can try to compile the code to be position-independent: 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 +will generate code that just loads the final symbol address from the +.I got (Global Offset Table) at run time before passing it to .BR dladdr (). .SH EXAMPLE -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
