From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18518 invoked by alias); 5 Feb 2003 19:08:38 -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 18510 invoked from network); 5 Feb 2003 19:08:38 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 5 Feb 2003 19:08:38 -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 NAA01149; Wed, 5 Feb 2003 13:58:12 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id OAA17021; Wed, 5 Feb 2003 14:08:37 -0500 Message-ID: <1ddf01c2cd49$eb05fca0$0202040a@catdog> From: "Kris Warkentin" To: "Paul Koning" Cc: , , , References: <032c01c2a60a$2368a6e0$0202040a@catdog><1021218002802.ZM4459@localhost.localdomain><15871.50596.942339.277490@pkoning.akdesign.com><08ab01c2b760$2e6612a0$0202040a@catdog> <15937.26809.680000.225947@gargle.gargle.HOWL> Subject: Re: relocation of shared libs not based at 0 Date: Wed, 05 Feb 2003 19:08: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: 2003-02/txt/msg00104.txt.bz2 I ran into the same problem: GDB was calculating that data in a shared lib was off by a page (1k hex) which was very annoying. The original patch that I had submitted doesn't seem to have this problem though so I went back and re-inserted it. The following is the code that I put into our qnx specific files. All I did then was set current_target_so_ops->relocate_section_addresses = qnx_relocate_section_addresses to override the System V behaviour and all my problems went away. cheers, Kris #include "solist.h" #include "solib-svr4.h" /* struct lm_info, LM_ADDR and qnx_truncate_ptr are copied from solib-svr4.c to support qnx_relocate_section_addresses which is different from the svr4 version. */ struct lm_info { /* Pointer to copy of link map from inferior. The type is char * rather than void *, so that we may use byte offsets to find the various fields without the need for a cast. */ char *lm; }; static CORE_ADDR LM_ADDR (struct so_list *so) { struct link_map_offsets *lmo = SVR4_FETCH_LINK_MAP_OFFSETS (); return (CORE_ADDR) extract_signed_integer (so->lm_info->lm + lmo->l_addr_offset, lmo->l_addr_size); } static CORE_ADDR qnx_truncate_ptr (CORE_ADDR addr) { if (TARGET_PTR_BIT == sizeof (CORE_ADDR) * 8) /* We don't need to truncate anything, and the bit twiddling below will fail due to overflow problems. */ return addr; else return addr & (((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1); } #include "elf-bfd.h" 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; } static void qnx_relocate_section_addresses (struct so_list *so, struct section_table *sec) { Elf32_Internal_Phdr *phdr = find_load_phdr(sec->bfd); unsigned vaddr = phdr?phdr->p_vaddr:0; sec->addr = qnx_truncate_ptr (sec->addr + LM_ADDR (so) - vaddr); sec->endaddr = qnx_truncate_ptr (sec->endaddr + LM_ADDR (so) - vaddr); } ----- Original Message ----- From: "Paul Koning" To: Cc: ; ; ; Sent: Wednesday, February 05, 2003 2:40 PM Subject: Re: relocation of shared libs not based at 0 > I'm resurrecting this thread to bring up a problem that's closely > related. > > On mips-netbsd, even after fixing the relocation problem (e.g., by the > patch I proposed earlier) gdb still has problems. Specifically, it > computes the wrong address for data within the shared library. > > After doing battle with various parts of gdb for quite some time, I > finally realized what the issue is. What puzzled me is that it works > just fine on netbsd-i386. That finally led me to the answer... > > The reason can be seen by looking at the symbol table. Here are > (partial) objdump runs, first for i386, then for mips: > > mainx86/libf3.so: file format elf32-i386 > > SYMBOL TABLE: > 000006fc l F .text 0000002b _strrchr > 00000000 F *UND* 00000000 __syscall > 0000083c w F .text 00000033 dlerror > 00000000 F *UND* 0000002b printf > 00001b80 g O .bss 00000004 __mainprog_obj > 00001b88 g O .bss 00000004 p > 00000934 g F .text 00000041 f3 > > mainmips/libf3.so: file format elf32-littlemips > > SYMBOL TABLE: > 5ffe10f0 F *UND* 00000034 __syscall > 5ffe0e20 w F *ABS* 00000000 dlerror > 5ffe1100 F *UND* 00000068 printf > 60021314 g O *ABS* 00000004 p > 5ffe1040 g F *ABS* 000000ac f3 > > The difference is that the mips symbol table has all symbols as *ABS*, > whether they are text (functions) or data. > > When the library is loaded, text and data are relocated separately > since they are two separate mmap regions. So the relocation bias is > different for the two. The i386 case works because the symbols are > correctly marked as to which region they belong to (text, data, bss). > But the mips case doesn't have that, so all symbol relocation is done > as if the symbols were text. The data and bss offsets are fine as > file offsets, but because the parts are mapped separately they are NOT > valid as memory address offsets. > > I'm wondering what the right way to fix this is. Two ways come to > mind: > > 1. Fix ld so it puts the right section designations on the symbols, > just as in the i386 case. > > 2. Hack gdb so it looks at the section headers in the shared library > file, to extract the start and length of the three regions. Use > that to identify the *ABS* symbols (i.e., p is bss since it's > within the vaddr range of the bss section in the section headers), > and then figure the correct relocation from that. > > I can do (2), and that has the advantage of working with existing > binaries, but it seems ugly. (1) sounds right. There are two issues > there, though. One is that I don't know ld. The other is that I'm > guessing there must be SOME reason why *ABS* is used for the mips > case, though I can't imagine any reason. > > Suggestions would be much appreciated. > > paul > >