From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12976 invoked by alias); 17 Dec 2002 20:23:42 -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 12888 invoked from network); 17 Dec 2002 20:23:41 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 17 Dec 2002 20:23:41 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id PAA08973 for ; Tue, 17 Dec 2002 15:17:30 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id PAA17673 for ; Tue, 17 Dec 2002 15:23:39 -0500 Message-ID: <032c01c2a60a$2368a6e0$0202040a@catdog> From: "Kris Warkentin" To: Subject: relocation of shared libs not based at 0 Date: Tue, 17 Dec 2002 12:23:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2002-12/txt/msg00255.txt.bz2 I recently came across a problem debugging a core file with some of our older shared libs. Info shared showed the relocations of the shared libs to be mangled (offset to 0x60... range rather than 0xb0... range). We had recently changed our tools to always set the vaddr of shared libs to be zero because of this but I was speaking to one of our architects and he says that this shouldn't be. One of the future optimizations we're looking at is pre-relocating shared libs so that they can be executed in place (on flash for instance) and the fact that the SysV stuff seems to assume that everything is based at zero is not particularily compatable with that. I've attached an ugly patch that shows a fix. This is for illustration only since solib.c is the wrong place to put this but it makes it clear what the issue is. Can anyone with more knowledge than I enlighten me as to a) whether it is proper to allow shared objects to be non zero-based and b) a better way to do this. I looked at putting it in solib-svr4.c but I don't have access to the bfd in there, at least in svr4_relocate_section_addresses(). cheers, Kris Index: solib.c =================================================================== RCS file: /product/tools/gdb/gdb/solib.c,v retrieving revision 1.4 diff -c -r1.4 solib.c *** solib.c 14 Nov 2002 20:57:23 -0000 1.4 --- solib.c 17 Dec 2002 20:10:14 -0000 *************** *** 26,31 **** --- 26,34 ---- #include #include "gdb_string.h" #include "symtab.h" + #ifdef __QNXTARGET__ + #include "elf-bfd.h" + #endif #include "bfd.h" #include "symfile.h" #include "objfiles.h" *************** *** 206,211 **** --- 209,229 ---- expansion stuff?). */ + #ifdef __QNXTARGET__ + Elf_Internal_Phdr *find_load_phdr( bfd *abfd ) + { + Elf32_Internal_Phdr *phdr; + unsigned int i; + + phdr = elf_tdata (abfd)->phdr; + for (i = 0; i < elf_elfheader (abfd)->e_phnum; i++, phdr++) { + if (phdr->p_type == PT_LOAD && (phdr->p_flags & PF_X)) + return phdr; + } + return NULL; + } + #endif + static int solib_map_sections (PTR arg) { *************** *** 263,268 **** --- 281,296 ---- object's file by the base address to which the object was actually mapped. */ TARGET_SO_RELOCATE_SECTION_ADDRESSES (so, p); + #ifdef __QNXTARGET__ + /* hack for solibs not based at 0 */ + { + Elf32_Internal_Phdr *phdr = find_load_phdr(abfd); + if(phdr){ + p->addr -= phdr->p_vaddr; + p->endaddr -= phdr->p_vaddr; + } + } + #endif if (STREQ (p->the_bfd_section->name, ".text")) { so->textsection = p;