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

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

[Joel Brobecker]

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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

>   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.

Sorry, I forgot the assembly file. Attached.

-- 
Joel

[-- Attachment #2: small.s --]
[-- Type: text/plain, Size: 2064 bytes --]

	.file	"small.c"
	.version	"01.01"
.stabs "/lot.a/brobecke/gdb-testsuite/tests/6423-010/",100,0,0,.Ltext0
.stabs "small.c",100,0,0,.Ltext0
.text
.Ltext0:
	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
.stabs "int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
.stabs "char:t(0,2)=r(0,2);0;127;",128,0,0,0
.stabs "long int:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0
.stabs "unsigned int:t(0,4)=r(0,4);0;-1;",128,0,0,0
.stabs "long unsigned int:t(0,5)=r(0,5);0;-1;",128,0,0,0
.stabs "long long int:t(0,6)=@s64;r(0,6);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "long long unsigned int:t(0,7)=@s64;r(0,7);0000000000000;01777777777777777777777;",128,0,0,0
.stabs "short int:t(0,8)=@s16;r(0,8);-32768;32767;",128,0,0,0
.stabs "short unsigned int:t(0,9)=@s16;r(0,9);0;65535;",128,0,0,0
.stabs "signed char:t(0,10)=@s8;r(0,10);-128;127;",128,0,0,0
.stabs "unsigned char:t(0,11)=@s8;r(0,11);0;255;",128,0,0,0
.stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
.stabs "double:t(0,13)=r(0,1);8;0;",128,0,0,0
.stabs "long double:t(0,14)=r(0,1);12;0;",128,0,0,0
.stabs "complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
.stabs "complex float:t(0,16)=r(0,16);4;0;",128,0,0,0
.stabs "complex double:t(0,17)=r(0,17);8;0;",128,0,0,0
.stabs "complex long double:t(0,18)=r(0,18);12;0;",128,0,0,0
.stabs "void:t(0,19)=(0,19)",128,0,0,0
.stabs "fat_pointer:T(0,20)=s8lb0:(0,1),0,32;array:(0,21)=*(0,2),32,32;;",128,0,0,0
.data
	.align 4
	.type	 fp.2,@object
	.size	 fp.2,8
fp.2:
	.long 0
	.long 0
.text
	.align 4
.stabs "main:F(0,1)",36,0,3,main
.globl main
	.type	 main,@function
main:
.stabn 68,0,3,.LM1-main
.LM1:
	pushl %ebp
	movl %esp,%ebp
.stabn 68,0,4,.LM2-main
.LM2:
.LBB2:
.stabn 68,0,12,.LM3-main
.LM3:
	cmpl $0,fp.2+4
	jne .L2
.L2:
.stabn 68,0,13,.LM4-main
.LM4:
.LBE2:
.stabn 68,0,13,.LM5-main
.LM5:
.L1:
	leave
	ret
.Lfe1:
	.size	 main,.Lfe1-main
.stabs "fp:V(0,20)",38,0,10,fp.2
.stabn 192,0,0,.LBB2-main
.stabn 224,0,0,.LBE2-main
.Lscope0:
.stabs "",36,0,0,.Lscope0-main
	.stabs "",100,0,0,.Letext
.Letext:
	.ident	"GCC: (GNU) 2.8.1"

Re: 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

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

[Joel Brobecker]

> So - 1) is elfstab_offset_sections working correctly?

I instrumented this function a bit, and it does not seem to work for me:
It looks like it is failing because it uses a chained list which head is

    objfile->sym_stab_info->stab_section_info

Unfortunately, this head seems to always be null...

I did not investigate further because I am hoping that all this is OBE
with a more recent version of x86-solaris. Unfortunately, I did not
receive any object file that I could check...

I'll also check whether gnu-as shows this problem or not...

Thanks for the feedback -
-- 
Joel