• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 20 subscribers
  • Views 954 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Incomplete/wrong debug information in AXF file produced by Arm Compiler 6.18?

Ezra

When running llvm-dwarfdump --verify Application.axf I get many "DIE address ranges are not contained in its parent's ranges" and "DIEs have overlapping address ranges" errors.

The first one seems to be due to incomplete entries in the .debug_ranges section, e.g.:

error: DIE address ranges are not contained in its parent's ranges:
0x000ef369: DW_TAG_compile_unit
              DW_AT_producer    ("Component: Arm Compiler for Embedded 6.18 Tool: armclang [5e4cc700]")
              DW_AT_language    (DW_LANG_C_plus_plus_14)
              DW_AT_name        ("foo.cpp")
              DW_AT_stmt_list   (0x00019750)
              DW_AT_comp_dir    ("/src")
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_ranges      (0x00006388
                 [0x00108764, 0x00108770)
                 [0x001062fc, 0x001063c2))

0x000f2545:   DW_TAG_subprogram
                DW_AT_low_pc    (0x0000000000107e28)
                DW_AT_high_pc   (0x0000000000107e52)
                DW_AT_frame_base        (DW_OP_reg13)
                DW_AT_GNU_all_call_sites        (true)
                DW_AT_linkage_name      ("_GLOBAL__sub_I_foo.cpp")
                DW_AT_artificial        (true)

Also, there are many entries in .debug_ranges that only contain <End of list>.

The second error is due to many functions reported to be located at address 0:

error: DIEs have overlapping address ranges:
0x000f271e: DW_TAG_subprogram
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_high_pc     (0x0000000000000010)
              DW_AT_frame_base  (DW_OP_reg13)
              DW_AT_GNU_all_call_sites  (true)
              DW_AT_linkage_name        ("_ZN4Edma15BarEj")
              DW_AT_name        ("Bar")
              DW_AT_decl_file   ("/src/bar.cpp")
              DW_AT_decl_line   (114)
              DW_AT_type        (0x000f7203 "bool")
              DW_AT_external    (true)

0x000f2676: DW_TAG_subprogram
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_high_pc     (0x0000000000000022)
              DW_AT_frame_base  (DW_OP_reg13)
              DW_AT_GNU_all_call_sites  (true)
              DW_AT_abstract_origin     (0x000f2698 "_ZN4SomethingEi")

I believe this is the reason that various implementations of the addr2line utility, GDB and LLDB cannot resolve the source code line numbers for certain addresses.

Might this be a bug in Arm Compiler 6 or am I missing something?

Any help is highly appreciated.

Cheers,

Ezra

Parents
  • 0

    Turns out that when armlink removes code it will set debug information references pointing to it to "dangling debug address" which is 0 by default. This seems to be allowed by the (DWARF 5) standard which reads:

    A bounded range entry whose beginning and ending address offsets are equal
(including zero) indicates an empty range and may be ignored.

    So, I understand that DWARF parsers technically should ignore the entries. But, I guess that would make parsing harder as they can be mistaken for "end of list" entries.

    The  "dangling debug address" can be changed with the --dangling-debug-address linker option, which fixes debugging with e.g. GDB or resolving addresses with addr2line.

    Anyway, IMHO the debug info is not ideal this way as one still gets errors when running e.g. llvm-dwarfdump --verify which is quite ugly.

Reply
  • 0

    Turns out that when armlink removes code it will set debug information references pointing to it to "dangling debug address" which is 0 by default. This seems to be allowed by the (DWARF 5) standard which reads:

    A bounded range entry whose beginning and ending address offsets are equal
(including zero) indicates an empty range and may be ignored.

    So, I understand that DWARF parsers technically should ignore the entries. But, I guess that would make parsing harder as they can be mistaken for "end of list" entries.

    The  "dangling debug address" can be changed with the --dangling-debug-address linker option, which fixes debugging with e.g. GDB or resolving addresses with addr2line.

    Anyway, IMHO the debug info is not ideal this way as one still gets errors when running e.g. llvm-dwarfdump --verify which is quite ugly.

Children
No data