From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5681 invoked by alias); 5 Apr 2002 16:47:24 -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 5673 invoked from network); 5 Apr 2002 16:47:23 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 5 Apr 2002 16:47:23 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16tWs9-0004NX-00 for ; Fri, 05 Apr 2002 11:47:33 -0500 Date: Fri, 05 Apr 2002 08:47:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: Does anyone use GDB on x86-solaris 2.7 or more recent? Message-ID: <20020405114733.A16497@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20020405182154.E31184@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020405182154.E31184@act-europe.fr> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00167.txt.bz2 On Fri, Apr 05, 2002 at 06:21:54PM +0200, Joel Brobecker wrote: > 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... Does it? Witness, in dbxread.c: /* If we're handling an ELF file, drag some section-relocation info for this source file out of the ELF symbol table, to compensate for Sun brain death. This replaces the section_offsets in this psymtab, if successful. */ elfstab_offset_sections (objfile, result); However, it does seem like we don't use those computed offsets for N_STSYM. The comment in elfread.c says we should: /* When handling an ELF file that contains Sun STABS debug info, some of the debug info is relative to the particular chunk of the section that was generated in its individual .o file. E.g. offsets to static variables are relative to the start of the data segment *for that module before linking*. This information is painfully squirreled away in the ELF symbol table as local symbols with wierd names. Go get 'em when needed. */ So - 1) is elfstab_offset_sections working correctly? 2) are we trying to use that information? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer