llvm-objdump: failed to parse debug information

Hi,

In a 32-bit ARM build, I am seeing the following warning (edited for
simplicity, I can provide full logs if necessary):

llvm-objdump -l -d -x file.elf
llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf

All object files and static libraries seem to have debug info (i.e.,
llvm-objdump does not complain when run on each file individually and
the disassembly output shows file/line information).

In order to identify where the ELF file is lacking debug info, I added
some debug traces to llvm-objdump and it seems the following symbol is
the culprit: __ThumbV7PILongThunk_<my_func>

Is this expected behavior? How to fix it?

LLVM version is llvmorg-11-init-12683-g54b3f91d205 but AFAICT anything
above 10.0 behaves the same.

Thanks,

What does llvm-dwarfdump tell you?

(particularly `--verify`)

-- adrian

Hi,

In a 32-bit ARM build, I am seeing the following warning (edited for
simplicity, I can provide full logs if necessary):

> llvm-objdump -l -d -x file.elf
> llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf

All object files and static libraries seem to have debug info (i.e.,
llvm-objdump does not complain when run on each file individually and
the disassembly output shows file/line information).

In order to identify where the ELF file is lacking debug info, I added
some debug traces to llvm-objdump and it seems the following symbol is
the culprit: __ThumbV7PILongThunk_<my_func>

Is this expected behavior? How to fix it?

It is expected that __ThumbV7PILongThunk_<my_func> has no debug information. A thunk is a linker generated code-sequence to extend the range of a branch. Usually we would want a debugger to step over these bits of code as they are largely there to bridge between functions the user wrote and are not interesting in their own right. There is also the practical consideration that there is no source code for these code-sequences; and as they are called between procedures they are limited in what state they can modify. For example a Thunk in Arm is only permitted to change the inter-procedural scratch register r12.

I would be surprised if missing debug information for a thunk would cause llvm-objdump to give an error message.

Hmmm... Quite a few errors actually, see here:

https://pastebin.com/9TBqyMM4

Hmm, those look like function’s that’ve been optimized out & that’s the expected DWARF for them - but the verify stuff was implemented by Apple folks focussing on the MachO debug info distribution model that doesn’t have that quirk. Would be good to fix the verifier to not hiccup on that sort of expected linked ELFine DWARF. (Adrian, etc?)

Agreed. However, these don’t look like reasons for llvm-objdump to choke.

–paulr

The reason I mentioned the thunk is because I added debug traces like so:

Hi,

In a 32-bit ARM build, I am seeing the following warning (edited for
simplicity, I can provide full logs if necessary):

> llvm-objdump -l -d -x file.elf
> llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf

All object files and static libraries seem to have debug info (i.e.,
llvm-objdump does not complain when run on each file individually and
the disassembly output shows file/line information).

In order to identify where the ELF file is lacking debug info, I added
some debug traces to llvm-objdump and it seems the following symbol is
the culprit: __ThumbV7PILongThunk_<my_func>

Is this expected behavior? How to fix it?

It is expected that __ThumbV7PILongThunk_<my_func> has no debug information. A thunk is a linker generated code-sequence to extend the range of a branch. Usually we would want a debugger to step over these bits of code as they are largely there to bridge between functions the user wrote and are not interesting in their own right. There is also the practical consideration that there is no source code for these code-sequences; and as they are called between procedures they are limited in what state they can modify. For example a Thunk in Arm is only permitted to change the inter-procedural scratch register r12.

I would be surprised if missing debug information for a thunk would cause llvm-objdump to give an error message.

The behavior was added by ⚙ D62462 [llvm-objdump] Add warning messages if disassembly + source for problematic inputs which intended to address 41905 – Add warning messages if disassembly + source for problematic inputs

I checked some arbitrary ARM/AArch64 programs (lld/test/ELF/*.s) with llvm-objdump -S,
`failed to parse debug information for file.elf` is very easy to trigger (when debug information is not available),
even with programs without thunks.

This seems to me that this particular needs improvement. I will look into this.

Sent ⚙ D88715 [llvm-objdump] --source: drop the warning when there is no debug info to drop the --source warning.