Summary: | objdump -dl and -WL disagree about initial state interpretation of the DWARF FSM | ||
---|---|---|---|
Product: | binutils | Reporter: | Achim <Stromeko> |
Component: | binutils | Assignee: | Nick Clifton <nickc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | nickc |
Priority: | P2 | ||
Version: | 2.41 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2023-08-22 00:00:00 | |
Attachments: |
objdump -dl
objdump -wWL Keyword.xs Keyword.c Keyword.dll (unstripped binary) Proposed patch |
Created attachment 15073 [details]
objdump -wWL
Created attachment 15074 [details]
Keyword.xs
Created attachment 15075 [details]
Keyword.c
Looking into Keyword.c (compilation unit) it is easy to see that the correct entry is line 37 in Keyword.xs for the first entry point. The corresponding line in Keyword.c would be line 46, but that was not emitted by the compiler due to the #line statement at line 9 of the compilation unit. Hi Achim, Please could you upload the compiled binary file so that I can run some local tests and try out a patch ? Cheers Nick Created attachment 15079 [details]
Keyword.dll (unstripped binary)
Created attachment 15481 [details]
Proposed patch
Hi Achim,
Thanks for the uploaded file. I think that I now understand the problem.
Please could you try out the uploaded patch and let me know if it works for you ?
Cheers
Nick
I've built 2.42 again with this patch applied and it fixes the problem (the objdump disassembly now correctly shows Keyboard.xs as the source file). The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d1765f5db3f9d1c75a3e1b06f0182db40afbbdc9 commit d1765f5db3f9d1c75a3e1b06f0182db40afbbdc9 Author: Nick Clifton <nickc@redhat.com> Date: Mon Apr 29 10:03:56 2024 +0100 Fix initiali state of DWARF v5 line number table in BFD library PR 30783 Great - patch applied. |
Created attachment 15072 [details] objdump -dl The DWARF-5 specification says that the file should be set to 1. While -WL implements that specification, -dl instead seems uses index 0 (which is the compilation unit). Therefore the output in the disassembly with line numbers listing is wrong when the files at index 0 and 1 are different until the FSM explicitly selects a different file index.