From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2626 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dladdr() Date: Wed, 16 Jan 2013 11:49:43 -0500 Message-ID: <20130116164943.GD20323@brightrain.aerifal.cx> References: <1358206649.32505.21@driftwood> <22145EB4-CF32-4BCA-8DE6-93790F3E267F@palsenberg.com> <1358254713.32505.27@driftwood> <1358261684.3766.10.camel@6-core> <20130115184820.GA20323@brightrain.aerifal.cx> <1358334018.2170.23.camel@6-core> <20130116125119.GA27914@port70.net> <50F6B818.1070807@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1358354998 23461 80.91.229.3 (16 Jan 2013 16:49:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jan 2013 16:49:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2627-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 16 17:50:16 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TvWBp-0000SU-0j for gllmg-musl@plane.gmane.org; Wed, 16 Jan 2013 17:50:13 +0100 Original-Received: (qmail 28379 invoked by uid 550); 16 Jan 2013 16:49:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28371 invoked from network); 16 Jan 2013 16:49:55 -0000 Content-Disposition: inline In-Reply-To: <50F6B818.1070807@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2626 Archived-At: On Wed, Jan 16, 2013 at 03:24:24PM +0100, musl wrote: > > i ran hello in gdb and it seems > > sym->st_shndx==0 > > for the "puts" symbol, i dont know the semantics of > > st_shndx, but the following patch makes hello.c work: > > > > diff --git a/src/ldso/dynlink.c b/src/ldso/dynlink.c > > index 935367e..ba0bd8f 100644 > > --- a/src/ldso/dynlink.c > > +++ b/src/ldso/dynlink.c > > @@ -1178,7 +1178,7 @@ int __dladdr(void *addr, Dl_info *info) > > } > > > > for (; nsym; nsym--, sym++) { > > - if (sym->st_shndx && sym->st_value > > + if (/*sym->st_shndx &&*/ sym->st_value > > && (1<<(sym->st_info&0xf) & OK_TYPES) > > && (1<<(sym->st_info>>4) & OK_BINDS)) { > > void *symaddr = p->base + sym->st_value; > > > > You're right, sym->st_shndx only tells if the symbol is external > (resolved during relocation process) or internal (defined in the > current shared object). st_shndx==0 is used for PLT entries. Oddly, I get (for hello.c): Symbol table '.dynsym' contains 9 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 FUNC GLOBAL DEFAULT UND printf 2: 080482c0 0 FUNC GLOBAL DEFAULT UND puts 3: 00000000 0 FUNC GLOBAL DEFAULT UND dladdr So the symbol value (the address of the PLT entry) seems to be filled in only for symbols which are also used to take the address of a function. Other symbols in the PLT (which are used only for resolving the PLT entry at load time) lack addresses. I suspect this could prevent correct dladdr behavior in some cases, but I can't think of a serious usage case that would be broken right off. Anyway, I'm applying nsz's patch (without the commented code :) which should make the situation much better (hopefully as good as glibc's). > BTW dli_fbase is still wrong. It should be > > info->dli_fbase = p->map; > > and not > > info->dli_fbase = p->base; I notice it disagrees with glibc, but I'm not sure I agree it's wrong. The man page states that dli_fbase is the "Address at which shared object is loaded", which is never clearly defined. On the other hand, dl_iterate_phdr's dlpi_addr is specified to contain the "Base address of object", which is defined below as "the difference between the virtual memory address of the shared object and the offset of that object in the file from which it was loaded". To me, this seems like the main/only "load address" that would be of interest to a program. However, there's also an interest in matching historical practice, especially since dladdr is not a standard function and the existing implementations could be seen as the "real" specification. Do you know what other systems like BSD do? Rich