From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16435 invoked by alias); 17 Dec 2002 20:31:58 -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 16423 invoked from network); 17 Dec 2002 20:31:55 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by sources.redhat.com with SMTP; 17 Dec 2002 20:31:55 -0000 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id gBHKVsQ22091 for ; Tue, 17 Dec 2002 15:31:54 -0500 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id gBHKVr622082; Tue, 17 Dec 2002 15:31:53 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id gBHKVrB13472; Tue, 17 Dec 2002 15:31:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15871.35257.357988.694515@pkoning.dev.equallogic.com> Date: Tue, 17 Dec 2002 12:31:00 -0000 From: Paul Koning To: kewarken@qnx.com Cc: gdb@sources.redhat.com Subject: Re: relocation of shared libs not based at 0 References: <032c01c2a60a$2368a6e0$0202040a@catdog> X-SW-Source: 2002-12/txt/msg00256.txt.bz2 >>>>> "Kris" == Kris Warkentin writes: Kris> I recently came across a problem debugging a core file with Kris> some of our older shared libs. Info shared showed the Kris> relocations of the shared libs to be mangled (offset to Kris> 0x60... range rather than 0xb0... range). We had recently Kris> changed our tools to always set the vaddr of shared libs to be Kris> zero because of this but I was speaking to one of our Kris> architects and he says that this shouldn't be. Kris> One of the future optimizations we're looking at is Kris> pre-relocating shared libs so that they can be executed in Kris> place (on flash for instance) and the fact that the SysV stuff Kris> seems to assume that everything is based at zero is not Kris> particularily compatable with that. I've attached an ugly Kris> patch that shows a fix. This is for illustration only since Kris> solib.c is the wrong place to put this but it makes it clear Kris> what the issue is. Kris> Can anyone with more knowledge than I enlighten me as to a) Kris> whether it is proper to allow shared objects to be non Kris> zero-based and b) a better way to do this. I looked at putting Kris> it in solib-svr4.c but I don't have access to the bfd in there, Kris> at least in svr4_relocate_section_addresses(). I ran into the same problem when trying to get gdb to deal correctly with shared libs on NetBSD/MIPS. The following patch is my attempt at dealing with it. I haven't tried to turn this into a patch submission because I don't trust my gdb hacking skills yet. Also, I was concentrating on "making it work" (for NetBSD/MIPS, the platform we needed to get right) rather than "doing the right thing" for gdb generally. BTW, this is a patch against a snapshot of 5.3 taken a few months ago. paul diff -u -r1.1.1.2 -r1.2 --- console_gdb/gdb/solib-svr4.c 2002/10/03 19:50:00 1.1.1.2 +++ console_gdb/gdb/solib-svr4.c 2002/10/07 20:45:23 1.2 @@ -1259,8 +1259,24 @@ svr4_relocate_section_addresses (struct so_list *so, struct section_table *sec) { +#if 0 /* wrong: LM_ADDR is the assigned address, not the offset */ sec->addr = svr4_truncate_ptr (sec->addr + LM_ADDR (so)); sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so)); +#else + /* The addresses are formed as follows: + LM_ADDR is the target address where the shared library file + is mapped. + So the actual section start address is LM_ADDR plus the section + offset within the shared library file. The end address is that + plus the section length. Note that we pay no attention to the + section start address as recorded in the library header. + */ + sec->endaddr = svr4_truncate_ptr (sec->endaddr - sec->addr + + sec->the_bfd_section->filepos + + LM_ADDR (so)); + sec->addr = svr4_truncate_ptr (sec->the_bfd_section->filepos + + LM_ADDR (so)); +#endif }