From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1157 invoked by alias); 5 Feb 2003 18:40:46 -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 1150 invoked from network); 5 Feb 2003 18:40:45 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by 172.16.49.205 with SMTP; 5 Feb 2003 18:40:45 -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 h15Iej604804 for ; Wed, 5 Feb 2003 13:40:45 -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 h15Ieir04792; Wed, 5 Feb 2003 13:40:44 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h15Iehx22225; Wed, 5 Feb 2003 13:40:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15937.26809.680000.225947@gargle.gargle.HOWL> Date: Wed, 05 Feb 2003 18:40:00 -0000 From: Paul Koning To: kewarken@qnx.com Cc: kevinb@redhat.com, gdb@sources.redhat.com, peterv@qnx.com, cburgess@qnx.com Subject: Re: relocation of shared libs not based at 0 References: <032c01c2a60a$2368a6e0$0202040a@catdog> <1021218002802.ZM4459@localhost.localdomain> <15871.50596.942339.277490@pkoning.akdesign.com> <08ab01c2b760$2e6612a0$0202040a@catdog> X-SW-Source: 2003-02/txt/msg00103.txt.bz2 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