[Bug binutils/17940] See unexpected diagnostic from msp430-elf-objdump BFD: Dwarf Error: mangled line number section.

[oarias at knights dot ucf.edu]

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.