From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19252 invoked by alias); 5 Feb 2003 19:11:01 -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 19240 invoked from network); 5 Feb 2003 19:11:01 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 5 Feb 2003 19:11:01 -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 h15JB0f14908 for ; Wed, 5 Feb 2003 14:11:00 -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 h15JB0a18310; Wed, 5 Feb 2003 14:11:00 -0500 Received: from localhost.localdomain (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h15JAxY32542; Wed, 5 Feb 2003 14:10:59 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h15JAsi03335; Wed, 5 Feb 2003 12:10:54 -0700 Date: Wed, 05 Feb 2003 19:11:00 -0000 From: Kevin Buettner Message-Id: <1030205191053.ZM3334@localhost.localdomain> In-Reply-To: Paul Koning "Re: relocation of shared libs not based at 0" (Feb 5, 2:40pm) 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> To: Paul Koning , kewarken@qnx.com Subject: Re: relocation of shared libs not based at 0 Cc: kevinb@redhat.com, gdb@sources.redhat.com, peterv@qnx.com, cburgess@qnx.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00105.txt.bz2 On Feb 5, 2:40pm, Paul Koning wrote: > 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. (1) sounds right to me too, though I share your concern that there may be some reason that ABS must be used the way it is for mips. I think you ought to ask about this on the binutils list... If you have to do (2), I strongly encourage you to create a new solib backend for it. Kevin