Bug 17940 - See unexpected diagnostic from msp430-elf-objdump BFD: Dwarf Error: mangled line number section.
Summary: See unexpected diagnostic from msp430-elf-objdump BFD: Dwarf Error: mangled l...
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.25
: P2 normal
Target Milestone: ---
Assignee: dj@redhat.com
URL: http://e2e.ti.com/support/development...
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-06 21:22 UTC by gmock
Modified: 2015-07-14 23:30 UTC (History)
3 users (show)

See Also:
Host:
Target: TI MSP430
Build:
Last reconfirmed: 2015-07-14 00:00:00


Attachments
Makefile (429 bytes, text/plain)
2015-07-13 12:12 UTC, Orlando Arias
Details
Generated ELF (2.71 KB, application/x-executable)
2015-07-13 12:13 UTC, Orlando Arias
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gmock 2015-02-06 21:22:50 UTC
% msp430-elf-gcc --version
msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-98)) (GNUPro 14r1)
(Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


% msp430-elf-objdump --version
GNU objdump (GNU Binutils) 2.24.51.20140505
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

% type hello.c
#include <stdio.h>

void main()
{
   printf("hello, world!\n");
}

% msp430-elf-gcc -fdata-sections -ffunction-sections -O0 -O2 -g -IC:\ti\gcc_3_02_02_00\include -mmcu=msp430f5529 -c hello.c

% msp430-elf-gcc -Wl,--gc-sections -Wl,--gc-sections -mmcu=msp430f5529 -Wl,-Map,hello.map hello.o -o hello.elf -LC:\ti\gcc_3_02_02_00\include

% msp430-elf-objdump -S hello.elf > dis.txt
BFD: Dwarf Error: mangled line number section.
BFD: Dwarf Error: mangled line number section.
BFD: Dwarf Error: mangled line number section.
<repeated many more times>
Comment 1 dj@redhat.com 2015-02-06 22:28:33 UTC
Reproduced
Comment 2 cvs-commit@gcc.gnu.org 2015-02-23 14:54:46 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0f8f0c57ea4742ad2d9b0598a18243331c1c06e3

commit 0f8f0c57ea4742ad2d9b0598a18243331c1c06e3
Author: Nick Clifton <nickc@redhat.com>
Date:   Mon Feb 23 14:53:02 2015 +0000

    Fixes the generation of dwarf line debug information for the msp430, even in the presence of function sections and linker garbage collection.
    
    	PR 17940
    	* dwarf2dbg.c (out_header): When generating dwarf sections use
    	real symbols not temps for the start and end symbols.
    	* config/tc-msp430.h (TC_FORCE_RELOCATION_SUB_SAME): Also prevent
    	adjustments to relocations in debug sections.
    	(TC_LINKRELAX_FIXUP): Likewise.
    
    	* elf32-msp430.c (msp430_elf_relax_delete_bytes): Adjust debug
    	symbols at end of sections.  Adjust function sizes.
Comment 3 Nick Clifton 2015-02-23 14:57:32 UTC
Hi George,

  This should be fixed now.

  The problem was two-fold.  Firstly the assembler was trying to resolve some of the symbol references used in the .debug_line section when it should have been leaving this job to the linker.  Secondly in the linker when relaxation reduced the size of a section it was not correctly updating all of the debug symbols attached to that section.

Cheers
  Nick
Comment 4 gmock 2015-03-09 19:18:17 UTC
Sorry for the delay in closing this one.  Thanks!  

-George
Comment 5 Orlando Arias 2015-07-10 08:22:19 UTC
Greetings,

I compiled the msp430-elf toolchain and I seem to have encountered this error even after applying the aforementioned patch. What is more, when disassembling the binary, I have encountered a few problems with the way label names are recorded in the resulting ELF.

$ msp430-elf-gcc -v
Using built-in specs.
COLLECT_GCC=msp430-elf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/msp430-elf/5.1.0/lto-wrapper
Target: msp430-elf
Configured with: ../configure --prefix=/usr --program-prefix=msp430-elf- --target=msp430-elf --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --disable-shared --disable-nls --disable-threads --enable-languages=c,c++ --enable-multilib --with-local-prefix=/usr/msp430-elf --with-sysroot=/usr/msp430-elf --with-as=/usr/bin/msp430-elf-as --with-ld=/usr/bin/msp430-elf-ld --disable-libgomp --enable-interwork --enable-addons : (reconfigured) ../configure --prefix=/usr --program-prefix=msp430-elf- --target=msp430-elf --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --disable-shared --disable-nls --disable-threads --enable-languages=c,c++ --enable-multilib --with-local-prefix=/usr/msp430-elf --with-sysroot=/usr/msp430-elf --with-as=/usr/bin/msp430-elf-as --with-ld=/usr/bin/msp430-elf-ld --disable-libgomp --enable-interwork --enable-addons : (reconfigured) ../configure --prefix=/usr --program-prefix=msp430-elf- --target=msp430-elf --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --disable-shared --disable-nls --disable-threads --enable-languages=c,c++ --enable-multilib --with-local-prefix=/usr/msp430-elf --with-sysroot=/usr/msp430-elf --with-as=/usr/bin/msp430-elf-as --with-ld=/usr/bin/msp430-elf-ld --disable-libgomp --enable-interwork --enable-addons
Thread model: single
gcc version 5.1.0 (GCC) 


$ msp430-elf-objdump -v
GNU objdump (GNU Binutils) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

$ msp430-elf-objdump -S blink.elf 2>/dev/null | hexdump -C | less
00002d50  33 35 35 36 09 09 3b 23  30 78 66 38 34 34 0a 0a  |3556..;#0xf844..|
00002d60  30 30 30 30 66 61 36 34  20 3c 4c 30 01 3e 3a 0a  |0000fa64 <L0.>:.|
00002d70  20 20 20 20 66 61 36 34  3a 09 62 30 20 31 32 20  |    fa64:.b0 12 |
00002d80  62 30 20 66 38 20 09 63  61 6c 6c 09 23 36 33 36  |b0 f8 .call.#636|
00002d90  36 34 09 09 3b 23 30 78  66 38 62 30 0a 0a 30 30  |64..;#0xf8b0..00|
00002da0  30 30 66 61 36 38 20 3c  4c 30 01 3e 3a 0a 20 20  |00fa68 <L0.>:.  |
00002db0  20 20 66 61 36 38 3a 09  33 30 20 34 31 20 20 20  |  fa68:.30 41   |
00002dc0  20 20 20 20 09 72 65 74  09 09 09 0a              |    .ret....|

[output trimmed, notice the 0x01 after L0]

$ cat main.c 
#include <msp430.h>

#ifdef __GNUC__
__attribute__((interrupt(TIMERA0_VECTOR)))
#else
#pragma vector=TIMER0_A0_VECTOR
#endif
void TimerA_vec(void) {
	P1OUT ^= 0xff;
}


int main(void) {
	WDTCTL = WDTPW | WDTHOLD;
	P1DIR = 0xff;
	P1OUT = 0x01;

	TACCR0 = 62499;
	TACCTL0 = CCIE;
	TACTL = (TASSEL1 | MC0 | ID1 | ID0);

	__bis_SR_register(CPUOFF | GIE);

	return 0;
}


I am changing the bug to unconfirmed provided that I do not know if this is a compilation issue on my side when building the toolchain or if it is a problem with binutils or newlib [or the compiler itself]. Thank you for your time and sorry for any inconvenience.

Cheers,
Orlando.
Comment 6 Orlando Arias 2015-07-13 12:12:48 UTC
Created attachment 8432 [details]
Makefile

Makefile to build source.
Comment 7 Orlando Arias 2015-07-13 12:13:29 UTC
Created attachment 8433 [details]
Generated ELF

Generated ELF.
Comment 8 Orlando Arias 2015-07-13 12:16:46 UTC
The bug [or a variation of it] seems to be still present in trunk. Returned by disassembler is the message:
msp430-elf-objdump: Dwarf Error: Line info data is bigger (0xfffffffc) than the section (0x118)
Furthermore, section labels in newlib are corrupted in a similar fashion. Bumping version number and providing generated ELF and Makefile to build the code. Thank you.

Cheers,
Orlando.
Comment 9 Nick Clifton 2015-07-14 14:21:47 UTC
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
Comment 10 Orlando Arias 2015-07-14 23:30:43 UTC
(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.