From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2630 Path: news.gmane.org!not-for-mail From: musl Newsgroups: gmane.linux.lib.musl.general Subject: Re: dladdr() Date: Wed, 16 Jan 2013 18:42:48 +0100 Message-ID: <50F6E698.3070604@gmail.com> 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> <20130116164943.GD20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1358358186 24030 80.91.229.3 (16 Jan 2013 17:43:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jan 2013 17:43:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2631-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 16 18:43:23 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 1TvX1G-0006si-3m for gllmg-musl@plane.gmane.org; Wed, 16 Jan 2013 18:43:22 +0100 Original-Received: (qmail 25867 invoked by uid 550); 16 Jan 2013 17:43:04 -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 25843 invoked from network); 16 Jan 2013 17:43:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QWvErpye+zJknd6y5W+HiSL9C4TLE2lHBiJVS9us07E=; b=KHcwLh1qZG9PaKFI09TM98MSTMDtKd04nuZL+b65nXsY/s7EsxSVnTDzjVgyz6UATt ipEpFgw4RbVFD0lQdT8LmxvamCUURnb3KZTvQrIkPt/UCL9dkRW9Zbz0oRPQZpn8+OCB 8tzJgbB/ikSY+fl6LB18QSdShhX+x398MtMkhmUxhRrbJCAv1VRN9bEsUWw8NeMLHjPV KZw9xGGQ78MmV0rZNIE7tGXjiFovT6WfxDJ/XEDPwVPyqE2d6ixVW1ltFnuPGc5cIkJz CMmcjSCtudfGLreq/IsFAacIeIbcXOHD6X9QbcORZRJr5O0mnKchgDPaKMeqBavk/CDu r6KQ== X-Received: by 10.152.113.66 with SMTP id iw2mr1921008lab.37.1358358171621; Wed, 16 Jan 2013 09:42:51 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 In-Reply-To: <20130116164943.GD20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2630 Archived-At: On 16/01/2013 17:49, Rich Felker wrote: > 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? freebsd dladdr man pages defines the dli_fbase field as : "The base address at which the shared object is mapped into the address space of the calling process" see: http://www.unix.com/man-page/FreeBSD/3/dladdr/ > > Rich >