https://sourceware.org/bugzilla/show_bug.cgi?id=17940
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2015-07-14
Ever confirmed|0 |1
--- Comment #9 from Nick Clifton <nickc at redhat dot com> ---
Hi Orlando,
> I compiled the msp430-elf toolchain and I seem to have encountered this
> error even after applying the aforementioned patch.
The problem I believe is in the linker script that you are using. This script
is not combining the partial .debug_line sections into a single, correct,
.debug_line section. Vis:
% readelf -S blink.elf
...
[13] .debug_line PROGBITS 00000000 0007a8 000118 00 0 0
1
[14] .debug_line.crt_0 PROGBITS 00000000 0008c0 000014 00 W 0 0
1
[15] .debug_line.crt_0 PROGBITS 00000000 0008d4 00007b 00 W 0 0
1
[16] .debug_line.fini PROGBITS 00000000 00094f 00001d 00 W 0 0
1
[17] .debug_ranges PROGBITS 00000000 00096c 000024 00 0 0
4
[18] .debug_line.crt_0 PROGBITS 00000000 000990 00001b 00 W 0 0
1
[19] .debug_line.crt_0 PROGBITS 00000000 0009ab 00000f 00 W 0 0
1
[20] .debug_line.init PROGBITS 00000000 0009ba 00001a 00 W 0 0
1
...
There should only be one .debug_line section in blink.elf.
I assume that you are using an MCU specific linker script. What you need to do
is to find the line that reads:
.debug_line 0 : { *(.debug_line) }
(It is probably near the end of the script). Replace it with this line:
.debug_line 0 : { *(.debug_line .debug_line.* .debug_line_end ) }
Then rebuild blink.elf.
What is happening is that when the assembler creates an object file it creates
lots of .debug_line.<foo> sections, one for each function in the input source
file. That way, if the linker garbage collection code decides to remove
function <foo> it can also remove the .debug_line.<foo> section associated with
that function, and so the line debug information remains consistent with the
actual code in the executable. But in order for this to work you need a linker
script that will combine all of the remaining .debug_line.<foo> sections into a
final, big, correct, .debug_line section.
> What is more, when
> disassembling the binary, I have encountered a few problems with the way
> label names are recorded in the resulting ELF.
> 00002da0 30 30 66 61 36 38 20 3c 4c 30 01 3e 3a 0a 20 20 |00fa68 <L0.>:.
> [output trimmed, notice the 0x01 after L0]
Actually this is correct. The .L0^A symbol is an assembler "Local Label".
Have a look in the assembler documentation for that name to see what is going
on...
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
