From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19463 invoked by alias); 15 Dec 2008 13:42:36 -0000 Received: (qmail 19451 invoked by uid 22791); 15 Dec 2008 13:42:35 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Dec 2008 13:42:00 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mBFDfIF3019924 for ; Mon, 15 Dec 2008 08:41:18 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBFDfH6Z021369 for ; Mon, 15 Dec 2008 08:41:17 -0500 Received: from [10.32.10.112] (vpn-10-112.str.redhat.com [10.32.10.112]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBFDfGnU019396; Mon, 15 Dec 2008 08:41:17 -0500 Subject: Re: dwfl_module_relocate_address() versus base address From: Mark Wielaard To: Roland McGrath Cc: systemtap In-Reply-To: <1229342761.3457.13.camel@dijkstra.wildebeest.org> References: <1229103422.3397.98.camel@dijkstra.wildebeest.org> <20081212200639.23B51FC3AB@magilla.sf.frob.com> <1229342761.3457.13.camel@dijkstra.wildebeest.org> Content-Type: multipart/mixed; boundary="=-GoDSmpq57J0ojJMrZW4D" Date: Mon, 15 Dec 2008 13:42:00 -0000 Message-Id: <1229348476.3457.16.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Virus-Checked: Checked by ClamAV on sourceware.org Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q4/txt/msg00566.txt.bz2 --=-GoDSmpq57J0ojJMrZW4D Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 506 Hi, On Mon, 2008-12-15 at 13:06 +0100, Mark Wielaard wrote: > Also for the kernel we still do things slightly differently (making > things relative to _stext) . I checked in the following patch to my > pr6866 branch and will be testing more with it. This is not completely true. I was confused since we also rely on the secname produced by dwfl_module_relocation_info() (being empty for ET_DYN). So that is now also replicated by hand in the new patch. It is getting slightly messy now :{ Cheers, Mark --=-GoDSmpq57J0ojJMrZW4D Content-Disposition: inline; filename="translate.patch" Content-Type: text/x-patch; name="translate.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit Content-length: 1394 diff --git a/translate.cxx b/translate.cxx index 27f6a04..bb976d5 100644 --- a/translate.cxx +++ b/translate.cxx @@ -4523,9 +4523,26 @@ dump_unwindsyms (Dwfl_Module *m, if (n > 0) // only try to relocate if there exist relocation bases { - int ki = dwfl_module_relocate_address (m, &sym_addr); - dwfl_assert ("dwfl_module_relocate_address", ki >= 0); - secname = dwfl_module_relocation_info (m, ki, NULL); + // libdwfl up to 0.137 could miscalculate the relocated + // address for shared ET_DYN files (n > 0). Luckily + // dwfl_module_address_section does work correctly. + // Then we just need to add the section offset to get + // the (relative) address of the symbol when mapped in. + Dwarf_Addr bias; + Elf_Scn *sec; + GElf_Shdr *shdr, shdr_mem; + GElf_Ehdr *ehdr, ehdr_mem; + Elf *elf; + sec = dwfl_module_address_section (m, &sym_addr, &bias); + dwfl_assert ("dwfl_module_address_section", sec != NULL); + shdr = gelf_getshdr(sec, &shdr_mem); + sym_addr += shdr->sh_offset; + elf = dwfl_module_getelf (m, &bias); + ehdr = gelf_getehdr(elf, &ehdr_mem); + if (ehdr->e_type == ET_DYN) + secname = ""; + else + secname = elf_strptr (elf, ehdr->e_shstrndx, shdr->sh_name); } if (n == 1 && modname == "kernel") --=-GoDSmpq57J0ojJMrZW4D--