Date: Sun, 18 Jan 1998 22:30:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jdp@polstra.com (John Polstra) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: dladdr hax Message-ID: <199801182230.PAA04997@usr04.primenet.com> In-Reply-To: <199801182223.OAA15844@austin.polstra.com> from "John Polstra" at Jan 18, 98 02:23:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > You aren't going to get what you probably thought you were going to > > get; spcifically, the libc symbol names will actually give you the > > address of the stub function linked from the shared library into the > > main program, not the address of the function in the C library. > > Yes, I know. That's why I wanted to see the output. I wanted to see > whether Solaris bothered to resolve those to their true addresses. > > > I pointed that out with my first test program and output (very > > similar to yours). > > Sorry, I didn't see that. I think the answers are slightly different between x86 and SPARC, as well. I would have to drive a bit (the weather here is currently terrible) to verify this. I think it has to do with the PLT implementation. I may be wrong; but it's kind of irrelevent anyway. The magic thing is that if you call it from *within* a shared library, the shared library can get to itself and know where it is located. This would actually be a *really* useful thing to do for name resolver which worked by finding .so's near the library so you could add arbitrary name spaces (X.25, ISO, XNS, SMB, etc.). It would also be useful for a "libauth" or something similar to implement PAM better than PAM implements it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801182230.PAA04997>