From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24200 invoked by alias); 5 Apr 2002 16:21:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24169 invoked from network); 5 Apr 2002 16:21:56 -0000 Received: from unknown (HELO dublin.ACT-Europe.FR) (212.157.227.154) by sources.redhat.com with SMTP; 5 Apr 2002 16:21:56 -0000 Received: from berlin.ACT-Europe.FR (berlin.int.act-europe.fr [10.10.0.169]) by dublin.ACT-Europe.FR (Postfix) with ESMTP id 0ED99229FF8 for ; Fri, 5 Apr 2002 18:21:54 +0200 (MET DST) Received: by berlin.ACT-Europe.FR (Postfix, from userid 507) id B1724960; Fri, 5 Apr 2002 18:21:54 +0200 (CEST) Date: Fri, 05 Apr 2002 08:21:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Does anyone use GDB on x86-solaris 2.7 or more recent? Message-ID: <20020405182154.E31184@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-SW-Source: 2002-04/txt/msg00162.txt.bz2 Hello, I'm chasing a problem that we are having with GDB on x86-solaris 2.6, and it all goes down to the address stored by the assembler for static symbols. I don't see this problem on sparc-solaris 2.8, which has a more recent version of the assembler, so I am wondering if newer versions of solaris distribute a more recent one, and if the problem is not fixed when using this more recent assembler. I can't find some documentation on the Sun website, so any feedback would be greatly appreciated. Could anyone do the following for me? Assemble the attached assembly file, and send me the object file. "gcc -c small.s" should do it. I'll then check the address of the static symbol using objdump. Here is a more detailed description of the problem. The problem was originally with an Ada program, but I managed to reproduce it in C. small.c: << int main (void) { struct fat_pointer { int lb0; char *array; }; static struct fat_pointer fp = { 0, 0}; if (fp.array == 0) {} } >> The assembly file when compiled with -g looks like: << fp.2: .long 0 .long 0 .stabs "fp:V(0,20)",38,0,10,fp.2 >> the variable "fp" is defined as a static variable, which is located at fp.2. The problem is that the assembler seems to be storing the address in the object file as an offset to the begining of the .data section *for this file*. The real issue starts after the link is performed, because the offset is not relative to the begining of the .data section anymore, since the linker concatenates all .data sections one after the other (and the linker did not perform any relocation on this stabs). As a side comment, note that GDB currently expects an absolute address... The relative adress can be observed using objdump --stabs: << Symnum n_type n_othr n_desc n_value n_strx String 29 STSYM 0 10 00000000 952 fp:V(0,20) ^^^^^^^^ >> And this causes the following error message in GDB: << This GDB was configured as "i386-pc-solaris2.6"... (gdb) b main Breakpoint 1 at 0x80488e7: file small.c, line 12. (gdb) run Starting program: /lot.a/brobecke/gdb-testsuite/tests/6423-010/small Breakpoint 1, main () at small.c:12 12 if (fp.array == 0) {} (gdb) p fp Cannot access memory at address 0x0 >> I don't see any easy way of computing the address from the relative offset. But since the assembler on sparc-solaris stores absolute addresses, I was hoping that this problem would go away just by doing an upgrade... Thanks, -- Joel