Bug 15994 - Different source code locations using the same addresses
Summary: Different source code locations using the same addresses
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.23
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2013-10-02 11:59 UTC by Harald Servat
Modified: 2013-10-24 11:18 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

Proposed patch - scan all CUs before reporting best match (1.99 KB, patch)
2013-10-22 15:04 UTC, Nick Clifton
Details | Diff
Slightly revised patch (1.99 KB, patch)
2013-10-22 16:36 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Servat 2013-10-02 11:59:31 UTC

  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

Thank you very much in advance!
Comment 1 Harald Servat 2013-10-02 12:00:52 UTC
The binary is too large for the bugzilla. You can grab a copy of the binary from:
Comment 2 Nick Clifton 2013-10-03 08:53:41 UTC
Please try the patch proposed for PR 15935

*** This bug has been marked as a duplicate of bug 15935 ***
Comment 3 Harald Servat 2013-10-03 09:14:47 UTC
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
  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

  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.
Comment 4 Nick Clifton 2013-10-22 15:04:09 UTC
Created attachment 7248 [details]
Proposed patch - scan all CUs before reporting best match
Comment 5 Nick Clifton 2013-10-22 15:05:05 UTC
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.

Comment 6 Harald Servat 2013-10-22 15:17:34 UTC
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
Comment 7 Nick Clifton 2013-10-22 16:17:50 UTC
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.

Comment 8 Harald Servat 2013-10-22 16:24:21 UTC
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!
Comment 9 Nick Clifton 2013-10-22 16:36:42 UTC
Created attachment 7249 [details]
Slightly revised patch

Hi Harald,

  Please try this revised patch...
Comment 10 Harald Servat 2013-10-23 07:52:15 UTC
Great! Now works like a charm!

Thank you very much Nick!
Comment 11 Nick Clifton 2013-10-24 11:18:37 UTC
Patch committed.