From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7568 invoked by alias); 17 Apr 2009 08:42:18 -0000 Received: (qmail 7560 invoked by uid 22791); 17 Apr 2009 08:42:17 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Apr 2009 08:42:12 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3H8gAMV030297 for ; Fri, 17 Apr 2009 04:42:11 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3H8gAm7007043; Fri, 17 Apr 2009 04:42:10 -0400 Received: from [10.32.10.157] (vpn-10-157.str.redhat.com [10.32.10.157]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3H8g829004200; Fri, 17 Apr 2009 04:42:08 -0400 Subject: Re: PR10000: emit _stp_relocate* calculations correctly for kernel/module global $data (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9-238-g432f054) From: Mark Wielaard To: Roland McGrath Cc: systemtap@sourceware.org In-Reply-To: <20090416205340.3FB31FC3C6@magilla.sf.frob.com> References: <20090327155519.19560.qmail@sourceware.org> <1239187983.3146.55.camel@fedora.wildebeest.org> <20090408124044.A0418FC351@magilla.sf.frob.com> <1239231131.9783.86.camel@hermans.wildebeest.org> <20090409005635.11D6CFC3E2@magilla.sf.frob.com> <1239286932.2442.54.camel@fedora.wildebeest.org> <20090413183258.4BDBEFC299@magilla.sf.frob.com> <1239877702.2334.51.camel@fedora.wildebeest.org> <20090416205340.3FB31FC3C6@magilla.sf.frob.com> Content-Type: text/plain Date: Fri, 17 Apr 2009 08:42:00 -0000 Message-Id: <1239957728.3224.46.camel@fedora.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2009-q2/txt/msg00302.txt.bz2 Hi Roland, On Thu, 2009-04-16 at 13:53 -0700, Roland McGrath wrote: > > Does libdwfl in offline mode guarantee that all ET_REL sections > > have a base themselves that falls inside the module start/end address? > > In offline mode, libdwfl lays out the sections all next to each other so > that there is a single contiguous module start..end. That is a nice feature to have in offline mode. > > So, for a different reason, since I needed the address range a ET_REL > > section covers for which we build a symbol table, > > I am not clear on why you are doing this. Why do you need this range? > I'd expected you'd just use dwfl_module_relocate_address and be done with it. [... rearranged ...] > > What I am doing is: > > - Loop through symbols with dwfl_module_getsymtab () and > > dwfl_module_getsym() (use > > For what again? Are you storing the whole symtab for runtime lookups or > something? Yes, we build a table of all function symbols, sorted by (relative) address, per relocation section, so at runtime we can easily lookup a symbol name given an address (keep track of where the sections are placed at runtime, then do a binary search through that table). We also need the size of the relocation sections to lookup other info for an address at runtime we associate with a module, like the unwind tables. > > I am now using > > dwfl_module_address_section () and then gelf_getshdr () on the returned > > Elf_Scn to get at the details of the section. Does this also introduce > > undesirable performance effects? > > Yes, it applies relocs to the section contents before returning. That is a pity, but this is only for a relocation section that contains an address of a symbol we are interested in (which admittedly is a larger number now that we also collect non-function symbol addresses). But I don't see any other way to get the individual relocation section sizes (in the ET_EXEC and ET_DYN cases it is easy, since then the relocation section size equals the module size for which we can get the start and end addresses through dwfl_module_info). Cheers, Mark