1

While trying to generate assembly code(intermixed with source code) using objdump,

gcc -g -c test.c ;
objdump -S -M intel test.o > out.asm

I get the following error.

BFD: Dwarf Error: mangled line number section.

The output assembly generated is not intermixed with source code. Could someone clarify what this means ? Is there anyway to fix this ?

Jean
  • 21,665
  • 24
  • 69
  • 119

2 Answers2

2

"objdump -S -M" is apparently expecting a ".debug_abbrev section" section in the .o file, and "gcc -g" apparently isn't writing it:

I don't think there's anything you can do about it (you're already using "-g" to include debug symbols). And I think it's completely safe to ignore.

The offending package is "binutils". Here's the complete code:

http://opensource.apple.com/source/binutils/binutils-20/src/bfd/dwarf2.c

/* In DWARF version 2, the description of the debugging information is
   stored in a separate .debug_abbrev section.  Before we read any
   dies from a section we read in all abbreviations and install them
   in a hash table.  */

static struct abbrev_info**
read_abbrevs (abfd, offset)
     bfd * abfd;
     unsigned int offset;
{
  struct abbrev_info **abbrevs;
  char *abbrev_ptr;
  struct abbrev_info *cur_abbrev;
  unsigned int abbrev_number, bytes_read, abbrev_name;
  unsigned int abbrev_form, hash_number;
  struct dwarf2_debug *stash;

  stash = elf_tdata(abfd)->dwarf2_find_line_info;

  if (! stash->dwarf_abbrev_buffer)
    {
      asection *msec;

      msec = bfd_get_section_by_name (abfd, ".debug_abbrev");
      if (! msec)
    {
      (*_bfd_error_handler) (_("Dwarf Error: Can't find .debug_abbrev section."));
      bfd_set_error (bfd_error_bad_value);
      return 0;
    }
paulsm4
  • 114,292
  • 17
  • 138
  • 190
2

This problem is typically showing a relocation table problem in .debug_line section caused by linker (ld) coding issue -- overlapped memory copy. The toolchain needs a bug fix and rebuild.

It will not affect program loading and running, but this problem will cause debugging impossible due to mismatching addresses/symbols. Here is an example and code is mangled at 0x0038ca82 (in bad linker case).

0038ca80 00 = op_code = DW_LNS_extended_op
0038ca81 05 = op length = 5 bytes
0038ca82 02 = extended_op_code = DW_LNE_set_address
0038ca83 nn nn nn nn = 4-byte address

In problematically linked ELF, the Extended op code (32 undefined)

0038ca82 32 = extended_op_code = Unknown -> mangled line number section

problem ld resulted ELF (mangled line number section):

0038ca60  62 6c 69 63 2e 68 00 01  00 00 68 65 61 70 5f 6d  |blic.h....heap_m|
0038ca70  67 72 5f 70 75 62 6c 69  63 2e 68 00 02 00 00 00  |gr_public.h.....|
0038ca80  00 05 32 00 40 18 02 94  32 00 40 00 01 01 00 05  |..2.@...2.@.....|
0038ca90  02 94 32 00 40 00 01 01  00 05 02 94 32 00 40 00  |..2.@.......2.@.|
0038caa0  01 01 00 05 32 00 40 15  02 b0 32 00 40 00 01 01  |....2.@...2.@...|
0038cab0  00 05 02 b0 32 00 40 00  01 01 00 05 02 b0 32 00  |....2.@.......2.|
0038cac0  40 00 01 01 00 05 02 c0  32 00 40 94 00 05 40 17  |@.......2.@...@.|

Normal ld resulted ELF:

0038ca60  62 6c 69 63 2e 68 00 01  00 00 68 65 61 70 5f 6d  |blic.h....heap_m|
0038ca70  67 72 5f 70 75 62 6c 69  63 2e 68 00 02 00 00 00  |gr_public.h.....|
0038ca80  00 05 02 80 32 00 40 38  00 05 02 80 32 00 40 18  |....2.@8....2.@.|
0038ca90  00 05 02 90 32 00 40 1a  00 05 02 94 32 00 40 00  |....2.@.....2.@.|
0038caa0  01 01 00 05 02 a0 32 00  40 49 00 05 02 a0 32 00  |......2.@I....2.|
0038cab0  40 15 00 05 02 ac 32 00  40 15 00 05 02 b0 32 00  |@.....2.@.....2.|
0038cac0  40 00 01 01 00 05 02 c0  32 00 40 94 00 05 02 c0  |@.......2.@.....|
jin guojun
  • 21
  • 2