https://sourceware.org/bugzilla/show_bug.cgi?id=17940
Orlando Arias <oarias at knights dot ucf.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Orlando Arias <oarias at knights dot ucf.edu> ---
(In reply to Nick Clifton from comment #9)
Greetings,
> 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.
This is indeed the case. I modified the linker script as requested and it works
as expected now. The linker script is among the ones TI offers on their website
for distribution. I opened a few ones at random and they all seem to contain
that line. Perhaps I should take this to them?
> 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...
Hmm... Unexpected. I will read on this. Thank you very much for your time.
Closing bug now as Fixed (change if necessary).
Cheers,
Orlando.
--
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
