large line number debugging support

large line number debugging support

[Paolo Molaro]

Hi.
I just added support to output stab information in the mono JIT
compiler: this debugging info is used to debug code generation problems
and as such the lines in the source code it references are from an
assembly dump of the CLR programs. For large libraries the assembly
files can be longer than 2^16 lines and the binary stabs format seems to use
16 bits unsigned integers to store line info.
Is there some kind of know workaround for this problem?
Splitting the assembly dump would be extremely ugly.

A somewhat related problem is symbol file info removal: it's possible to
add a symbol file at runtime inside gdb, but I haven't found a way to
unload it once I need to restart the program (and I need to restart gdb
as well).

I'm not on the list, so please, Cc me on any replies.
Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better

large line number debugging support

[Paolo Molaro]

Hi.
I just added support to output stab information in the mono JIT
compiler: this debugging info is used to debug code generation problems
and as such the lines in the source code it references are from an
assembly dump of the CLR programs. For large libraries the assembly
files can be longer than 2^16 lines and the binary stabs format seems to use
16 bits unsigned integers to store line info.
Is there some kind of know workaround for this problem?
Splitting the assembly dump would be extremely ugly.

A somewhat related problem is symbol file info removal: it's possible to
add a symbol file at runtime inside gdb, but I haven't found a way to
unload it once I need to restart the program (and I need to restart gdb
as well).

I'm not on the list, so please, Cc me on any replies.
Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better

Re: large line number debugging support

[Andrew Cagney]

> Hi.
> I just added support to output stab information in the mono JIT
> compiler: this debugging info is used to debug code generation problems
> and as such the lines in the source code it references are from an
> assembly dump of the CLR programs. For large libraries the assembly
> files can be longer than 2^16 lines and the binary stabs format seems to use
> 16 bits unsigned integers to store line info.
> Is there some kind of know workaround for this problem?
> Splitting the assembly dump would be extremely ugly.


How does dwarf2 go with this?  ``gas -gdwarf2'' will select dwarf2 
assembler debug info.

Andrew

Re: large line number debugging support

[Daniel Berlin]

On Sat, 15 Dec 2001, Andrew Cagney wrote:

> > Hi.
> > I just added support to output stab information in the mono JIT
> > compiler: this debugging info is used to debug code generation problems
> > and as such the lines in the source code it references are from an
> > assembly dump of the CLR programs. For large libraries the assembly
> > files can be longer than 2^16 lines and the binary stabs format seems to use
> > 16 bits unsigned integers to store line info.
> > Is there some kind of know workaround for this problem?
> > Splitting the assembly dump would be extremely ugly.
>
>
> How does dwarf2 go with this?  ``gas -gdwarf2'' will select dwarf2
> assembler debug info.

DWARF2 can do line numbers as large as you like, the opcodes take leb128
or sleb128, as opposed to some fixed size encoding.

>
> Andrew
>
>
>

Re: large line number debugging support

[Paolo Molaro]

On 12/15/01 Daniel Berlin wrote:
> > How does dwarf2 go with this?  ``gas -gdwarf2'' will select dwarf2
> > assembler debug info.
> 
> DWARF2 can do line numbers as large as you like, the opcodes take leb128
> or sleb128, as opposed to some fixed size encoding.

Uhm, still no luck:

$ cat test-stabs.s
.stabs "corlib.il",100,0,0,0
.stabs "Void:t(0,1)=(0,1)",128,0,0,0
.stabs "myfunc:F(0,1)",36,0,70000,0x0
.stabs "",36,0,0,204

$ as -gdwarf2 test-stabs.s -o test-stabs.o
$ objdump -G test-stabs.o

test-stabs.o:     file format elf32-i386

Contents of .stab section:

Symnum n_type n_othr n_desc n_value  n_strx String

-1     HdrSym 0      4      00000038 1     
0      SO     0      0      00000000 14     corlib.il
1      LSYM   0      0      00000000 24     Void:t(0,1)=(0,1)
2      FUN    0      4464   00000000 42     myfunc:F(0,1)
3      FUN    0      0      000000cc 0      

$ echo $((70000-4464))
65536

It's still trucated at 65536. So, even if the information is saved in
the file (from an hexdump it doesn't look so), it's not used correctly
by objdump and gdb.
My binutils version is:
binutils           2.11.92.0.12.3-3

Maybe I'm just doing something silly?
Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better

Re: large line number debugging support

[Joel Brobecker]

> $ cat test-stabs.s
> .stabs "corlib.il",100,0,0,0
> .stabs "Void:t(0,1)=(0,1)",128,0,0,0
> .stabs "myfunc:F(0,1)",36,0,70000,0x0
> .stabs "",36,0,0,204
> 
> $ as -gdwarf2 test-stabs.s -o test-stabs.o

It is not the assembler that generates the DWARF2 information, but the
compiler.  Compile with -gdwarf-2 from the begining and it should work
better.

-- 
Joel

Re: large line number debugging support

[Daniel Berlin]

On Wed, 19 Dec 2001, Paolo Molaro wrote:

> On 12/15/01 Daniel Berlin wrote:
> > > How does dwarf2 go with this?  ``gas -gdwarf2'' will select dwarf2
> > > assembler debug info.
> >
> > DWARF2 can do line numbers as large as you like, the opcodes take leb128
> > or sleb128, as opposed to some fixed size encoding.
>
> Uhm, still no luck:
>
> $ cat test-stabs.s
> .stabs "corlib.il",100,0,0,0
> .stabs "Void:t(0,1)=(0,1)",128,0,0,0
> .stabs "myfunc:F(0,1)",36,0,70000,0x0
> .stabs "",36,0,0,204
>
> $ as -gdwarf2 test-stabs.s -o test-stabs.o
> $ objdump -G test-stabs.o
>
> test-stabs.o:     file format elf32-i386
>
> Contents of .stab section:
>
> Symnum n_type n_othr n_desc n_value  n_strx String
>
> -1     HdrSym 0      4      00000038 1
> 0      SO     0      0      00000000 14     corlib.il
> 1      LSYM   0      0      00000000 24     Void:t(0,1)=(0,1)
> 2      FUN    0      4464   00000000 42     myfunc:F(0,1)
> 3      FUN    0      0      000000cc 0
>
> $ echo $((70000-4464))
> 65536
>
> It's still trucated at 65536. So, even if the information is saved in
> the file (from an hexdump it doesn't look so), it's not used correctly
> by objdump and gdb.
> My binutils version is:
> binutils           2.11.92.0.12.3-3
>
> Maybe I'm just doing something silly?

as -gdwarf-2 would generate line number debug info for the *assembler
source*, not translate your stabs commands into dwarf2 ones.
You need to output dwarf2 info instead of stabs.