From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5061 invoked by alias); 9 Jan 2004 22:48:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5039 invoked from network); 9 Jan 2004 22:48:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 Jan 2004 22:48:28 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i09MmRg08485 for ; Fri, 9 Jan 2004 17:48:27 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i09MmRE11803; Fri, 9 Jan 2004 17:48:27 -0500 Received: from localhost.localdomain (vpn50-10.rdu.redhat.com [172.16.50.10]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i09MmQnm001022; Fri, 9 Jan 2004 17:48:27 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id i09MmLt14160; Fri, 9 Jan 2004 15:48:21 -0700 Date: Fri, 09 Jan 2004 22:48:00 -0000 From: Kevin Buettner Message-Id: <1040109224820.ZM14159@localhost.localdomain> In-Reply-To: Paul Koning "RE: relocation of shared libs not based at 0" (Jan 5, 12:39pm) References: <16377.41315.519376.660039@gargle.gargle.HOWL> To: Paul Koning , gdb@sources.redhat.com Subject: Re: relocation of shared libs not based at 0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg00130.txt.bz2 On Jan 5, 12:39pm, Paul Koning wrote: > So the real answer is simple: the LM_ADDR entries have to be adjusted > by the as-linked start VMA of the library. The only problem I ran > into is that I couldn't find a clean way to obtain that value in gdb. > I did come up with something that worked; if there are better ways to > do this I would be interested. > > My fix is in a modified 5.3, but the relevant source is unchanged from > 5.3 to 6.0. So attached is a diff for 6.0 that shows the fix I > described. > > paul > > --- gdb/solib-svr4.c.orig Fri Jun 13 17:56:27 2003 > +++ gdb/solib-svr4.c Mon Jan 5 12:29:49 2004 > @@ -1375,8 +1375,29 @@ > svr4_relocate_section_addresses (struct so_list *so, > struct section_table *sec) > { > - sec->addr = svr4_truncate_ptr (sec->addr + LM_ADDR (so)); > - sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so)); > + CORE_ADDR reloc; > + > + /* On NetBSD/MIPS at least, the library is mapped in two pieces. > + The section headers describe this: each shows the unrelocated > + virtual address of the section. To figure out the relocated > + address, we have to adjust these by the base VMA of the library. > + > + There isn't a really clean way to figure out the offset of each > + section. "filepos" doesn't do it, because that is the > + file-relative offset, not the VMA offset. > + > + So what we do is this: > + Pick up the VMA (given by the header) of the first section, > + and subtract from that its filepos. That's the unrelocated VMA > + of the library. Subtract that from the unrelocated VMA > + of each section to get its relocation bias; add that to the > + library load address to get the relocated address. > + */ > + reloc = so->sections->the_bfd_section->vma - > + so->sections->the_bfd_section->filepos; > + > + sec->endaddr = svr4_truncate_ptr (sec->endaddr - reloc + LM_ADDR (so)); > + sec->addr = svr4_truncate_ptr (sec->addr - reloc + LM_ADDR (so)); > } I think something along these lines will be okay. It may even be okay as is. I need to study the relationship between "vma" and "filepos" to convince myself that it's okay. I'll be very busy with other matters for the next couple of weeks. Would you mind pinging me in a few weeks? In the interim, I'd like to find out what the QNX folks think of this patch. As I recall, QNX behaved in a similar fashion to NetBSD and I'm wondering if Paul's patch would address those problems as well. Kevin