llvm dev - Apr 2020 - 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,
-- 
Jerome

What does llvm-dwarfdump tell you?

On Tue, Apr 28, 2020 at 8:57 AM Jerome Forissier via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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,
> --
> Jerome
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/c6b63b61/attachment.html>

> On Apr 28, 2020, at 9:03 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 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.

> Thanks,
> --
>Jerome
________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Jerome
Forissier via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 28 April 2020 15:23
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] 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,
--
Jerome
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 4/28/20 6:19 PM, Peter Smith wrote:
>> 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 reason I mentioned the thunk is because I added debug traces like so:

===diff --git a/llvm/tools/llvm-objdump/llvm-objdump.cpp
b/llvm/tools/llvm-objdump/llvm-objdump.cpp
index 92c130be113..ae1c02d49e8 100644
--- a/llvm/tools/llvm-objdump/llvm-objdump.cpp
+++ b/llvm/tools/llvm-objdump/llvm-objdump.cpp
@@ -638,7 +638,9 @@ void SourcePrinter::printSourceLine(raw_ostream &OS,
   if (LineInfo.FileName == DILineInfo::BadString) {
     if (!WarnedNoDebugInfo) {
       std::string Warning -          "failed to parse debug information
for " + ObjectFilename.str();
+          "failed to parse debug information for " +
ObjectFilename.str() +
+	  " Address " + to_string(Address.Address) + " SectionIndex
" +
+	  to_string(Address.SectionIndex);
       if (!ErrorMessage.empty())
         Warning += ": " + ErrorMessage;
       reportWarning(Warning, ObjectFilename);
===
Which gives:

$ llvm-objdump -l ldelf.elf >/dev/null
llvm-objdump: warning: 'ldelf.elf': failed to parse debug information
for ldelf.elf Address 19404 SectionIndex 1

And readelf reports (note that 0x4bcc == 19404):

$ arm-linux-gnueabihf-readelf -a ldelf.elf | grep -E '(]
\.text|<.*Thunk)'
  [ 1] .text             PROGBITS        00000000 001000 004bd8 00  AX  0   0  4
0x4bcc <__ThumbV7PILongThunk_utee_log>: 0x1 [cantunwind]

-- 
Jerome
> 
> 
>> Thanks,
>> --
>> Jerome
> 
> ________________________________________
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Jerome Forissier via llvm-dev <llvm-dev at lists.llvm.org>
> Sent: 28 April 2020 15:23
> To: llvm-dev at lists.llvm.org
> Subject: [llvm-dev] 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,
> --
> Jerome
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On 2020-04-28, Peter Smith via llvm-dev wrote:
>> 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 https://reviews.llvm.org/D62462 which intended to
address https://bugs.llvm.org/show_bug.cgi?id=41905

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.
>
>> Thanks,
>> --
>>Jerome
>
>________________________________________
>From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Jerome Forissier via llvm-dev <llvm-dev at lists.llvm.org>
>Sent: 28 April 2020 15:23
>To: llvm-dev at lists.llvm.org
>Subject: [llvm-dev] 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,
>--
>Jerome
>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev