Re: [Simulavr-devel] Problem with gdb (not simulavr)

[Theodore A. Roth]

On Mon, 31 Dec 2001, Tak Auyeung wrote:

:)The following is what I got when stepping through test_blink.asm in gdb-5.1:
:)
:)--snip--
:)(gdb) load a.out
:)Loading section .text, size 0x3a lma 0x0
:)Start address 0x0, load size 58
:)Transfer rate: 464 bits in <1 sec, 29 bytes/write.
:)(gdb) symbol-file a.out
:)Load new symbol table from "a.out"? (y or n) y
:)Reading symbols from a.out...done.
:)(gdb) stepi
:)0x0000001a      50      LOOP:   rjmp    LIGHTS          ; go into an 
:)infinite loop
:)(gdb) stepi

--snip--

:)You can see that stepi works, but the debugger fails to show which line 
:)is to be executed next (always shows line 50) even though it seems to 
:)understand the current PC correctly.
:)

I've been thinking about this problem with the line numbers being wrong. I 
believe that the assembler is not generating the correct symbol table 
information. I added "--gstabs" to the .asm.elf rule in Makefile_AVR_Rules 
and rebuilt the test_asm files. Here's what I got from the test_blink.lst 
file for the .stab section:

Contents of .stab section:

Symnum n_type n_othr n_desc n_value  n_strx String

-1     HdrSym 0      30     00000069 1
0      SO     0      0      00000000 53     
../../../simulavr/test_asm/test_8515/test_blink.asm
1      SLINE  0      15     00000000 0 
2      SLINE  0      16     00000000 0 
3      SLINE  0      17     00000000 0 
4      SLINE  0      18     00000000 0 
5      SLINE  0      19     00000000 0 
6      SLINE  0      20     00000000 0 
7      SLINE  0      21     00000000 0 
8      SLINE  0      22     00000000 0 
9      SLINE  0      23     00000000 0 
10     SLINE  0      24     00000000 0 
11     SLINE  0      25     00000000 0 
12     SLINE  0      26     00000000 0 
13     SLINE  0      27     00000000 0 
14     SLINE  0      29     00000000 0 
15     SLINE  0      30     00000000 0 
16     SLINE  0      31     00000000 0 
17     SLINE  0      33     00000000 0 
18     SLINE  0      35     00000000 0 
19     SLINE  0      36     00000000 0 
20     SLINE  0      37     00000000 0 
21     SLINE  0      39     00000000 0 
22     SLINE  0      41     00000000 0 
23     SLINE  0      42     00000000 0 
24     SLINE  0      43     00000000 0 
25     SLINE  0      45     00000000 0 
26     SLINE  0      46     00000000 0 
27     SLINE  0      47     00000000 0 
28     SLINE  0      49     00000000 0 
29     SLINE  0      50     00000000 0 


For the SLINE entries, the 5th col (n_value) should be the address (PC) in
the flash which coresponds to the line of the asm file in the 4th col
(n_desc). This would explain why gdb always says it's on line 50. The line
numbers seem to be correct.

It seems to me that the assembler should have no problem putting the 
addresses in there.

Scott Finneran had a problem with avr-gcc compiling a C program with "-g
-Wa,-gstabs". He'd get object files having symbol table entries with both
the C source and the .s intermediate asm source combined. Needless to say,
this confused the hell out of gdb. I'm wondering if there might be a
general bug (not avr specific) in either gcc or the assembler.

Has anyone tried the just released gcc-3.0.3 yet?

Ted