Re: GDB can not read debug symbols

* Orlando Arias <[email protected]> [2015-09-30 13:27:42 -0400]:

> Greetings,
> 
> As asked in IRC, here is some more debug information obtained from GDB
> as the file is opened, a connection to the remote stub is established, a
> breakpoint is set, execution is triggered and stepping inside main() is
> attempted. These logs are provided as an attachment. I am not entirely
> sure what I am looking at here, but it seems that GDB is not populating
> line numbers for some of the compilation units, although the data is
> available.
> 
> Any help would be appreciated. Thank you.

I took a look at the line information, and noticed that the address
ranges covered by crt0.S seem to span over the address range covered
by test.c, so crt0.S runs from 0xf810 to 0xfa52 while test.c runs from
0xf924 to 0xf95c.  I've frequently run into this problem when linker
relaxation is corrupting the generated DWARF.

I took a look at the msp430 linker, and noticed that linker relaxation
is used by default, in-fact a comment suggests it's required for
correct operation, so my normal suggestion, turn linker relaxation off
and see if your problem goes away appears to be a non-starter.

When linker relaxation is used then care must be taken to ensure that
the DWARF is not corrupted.  Some DWARF constructs will generate the
difference of two symbol.  If this difference is resolved in the
assembler and linker relaxation reduces the number of bytes between
the start and end points then the encoded DWARF will be wrong.

There are two solutions to this problem, one is to make use of DIFF
style relocations to leave the resolution of the difference until the
linker, after linker relaxation has taken place.  The other solution
is to adjust the DWARF that is generated, so, the DWARF actually
allows for two difference ways to encode an address range, the
original way is a start address and a length, later versions of DWARF
allowed, as an alternative a start and end address to be used.
Switching to the start/end model removes the need to support
difference relocations.

To determine if the problem above really is the cause of your
debugging issues I would ask for the following additional information,
first, recompile your program with the addition of
'-Wl,--emit-relocs', then run the following command
'msp430-elf-objdump -rW test.elf' and send the output.

The '-r' will display all the relocations, while '-W' will display all
of the DWARF, not just the (decoded) line table, with these two things
we'll be able to see if the DWARF is making use of start + length
style encoding, and then check to see which relocations are generated.

Hope that helps,
Thanks,
Andrew