Hello, I have a binary (attached) that reports different source code locations for the same address. For instance, when querying to addresses 0x4f5cf5, 0x4f5be8, and (again) 0x4f5cf5, we observe that the source code reference for the repeated address differs. # addr2line -fe ./nest 0x4f5cf5 main /home/Computational/harald/analysis-apps/nest-2.2.2/nest/main.cpp:43 0x4f5be8 _start /home/Computational/harald/analysis-apps/nest-2.2.2/sli/slitype.cc:56 0x4f5cf5 main /home/Computational/harald/analysis-apps/nest-2.2.2/sli/slitype.cc:56 Thank you very much in advance!
The binary is too large for the bugzilla. You can grab a copy of the binary from: https://db.tt/yq9Njy7t
Please try the patch proposed for PR 15935 *** This bug has been marked as a duplicate of bug 15935 ***
Dear Nick, and others, yes, there probably is some weird information in the debugging information, and I'd like to inform the compiler devels, if possible. I tried to use readelf -wl with the binary, and for the first query, I guess that the following info is using Line Number Statements: Extended opcode 2: set Address to 0x4f5ca0 Advance Line by 36 to 37 Copy Extended opcode 2: set Address to 0x4f5cd7 Special opcode 3: advance Address by 0 to 0x4f5cd7 and Line by 2 to 39 Extended opcode 2: set Address to 0x4f5cec Advance Line by 4 to 43 Copy But I can't get any pointer for the second query (0x4f5be8) it does not translated. In fact, readelf -wl reports the first address as Extended opcode 2: set Address to 0x4f5ca0 so is that a problem from the debugging information? Or should addr2line give an error indicating that the address is not within the binary bounds? And besides this, why this alters the third query, which seems to be correctly translated earlier? Thank you.
Created attachment 7248 [details] Proposed patch - scan all CUs before reporting best match
Hi Harald, Sorry - the patch for PR 15935 appears to have gone AWOL. So instead please try out the uploaded, slightly tweaked version, and let me know if it works for you. Cheers Nick
Thank you Nick! It seems that the situation has improved, however there's a slightly issue with respect to the source file. If I repeat the process now (2.23.2+patch) adds libltdl/.libs in the second query where it wasn't on the first. Would it be possible to have the same source file for both? # ~/aplic/binutils/2.23.2-p/bin/addr2line -fe nest 0x4f5cf5 main /home/Computational/harald/analysis-apps/nest-2.2.2/nest/main.cpp:43 0x4f5be8 _start /home/Computational/harald/analysis-apps/nest-2.2.2/sli/slitype.cc:56 0x4f5cf5 main /home/Computational/harald/analysis-apps/nest-2.2.2/libltdl/.libs/main.cpp:43
Hi Harald, I saw this too.... > main > /home/Computational/harald/analysis-apps/nest-2.2.2/nest/main.cpp:43 > main > /home/Computational/harald/analysis-apps/nest-2.2.2/libltdl/.libs/main.cpp:43 Which one is correct ? I have been trying to look through the debug info to determine what the correct result should be, but I am getting confusing results. Cheers Nick
Hello Nick, my guess is the second is wrong, because the .cpp file is not meant to be in libtdl/.libs when built by the libtool. Is it possible to have a unique output for both? If not, I guess I can still work only with the filename only and skip the directory name. However, I guess that may not suffice for everyone. Thank you very much!
Created attachment 7249 [details] Slightly revised patch Hi Harald, Please try this revised patch...
Great! Now works like a charm! Thank you very much Nick!
Patch committed.
Hello, I have an ELF file that goes through the binutils-2.37 objdump -d --source in about a minute, but through the same command of binutils-2.23.2 in about 4 seconds. The output in both cases is identical. Bisection points to this commit as the reason for the slowdown. Unfortunately I cannot share that ELF file.
(In reply to jcmvbkbc from comment #12) > Hello, > > I have an ELF file that goes through the binutils-2.37 objdump -d --source > in about a minute, but through the same command of binutils-2.23.2 in about > 4 seconds. The output in both cases is identical. Bisection points to this > commit as the reason for the slowdown. Unfortunately I cannot share that ELF > file. Please open a new bug report.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=924cf858c94ebc3f54e1e2e0710099fb94e2c901 commit 924cf858c94ebc3f54e1e2e0710099fb94e2c901 Author: Alan Modra <amodra@gmail.com> Date: Thu Mar 24 15:42:52 2022 +1030 Revert commit 240d6706c6a2 PR 28592 PR 15994 PR 15935 * dwarf2.c (lookup_address_in_line_info_table): Return bool rather than a range. (comp_unit_find_nearest_line): Likewise. Return true if function info found without line info. (_bfd_dwarf2_find_nearest_line): Revert range handling code.