Does anyone use GDB on x86-solaris 2.7 or more recent?

[Daniel Jacobowitz]

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