Bug 1292563 - [LLNL 7.5 FEAT] Provide API to access all link maps, including those from dlmopen (gdb)
[LLNL 7.5 FEAT] Provide API to access all link maps, including those from dlm...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdb (Show other bugs)
All Linux
high Severity high
: rc
: 7.5
Assigned To: Jan Kratochvil
: FutureFeature
Depends On:
Blocks: 1400611
  Show dependency treegraph
Reported: 2015-12-17 14:30 EST by Ben Woodard
Modified: 2017-10-18 15:53 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1265827
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 15971 None None None 2015-12-17 14:30 EST

  None (edit)
Comment 1 Ben Woodard 2015-12-17 14:32:51 EST
This work includes not only changes to glibc but also changes to gdb to make use of this new function and make it available to gdb users.
Comment 4 Ben Woodard 2017-01-11 15:39:45 EST
Another thing at least tangentially associated with this RFE that came up in the last meeting which included Carlos and a few people from LLNL is that they also need first party access to these things. They said that one of our weaknesses is all of our tools interfaces seem to be designed to be 3rd party. So a debugger like GDB can remotely access an app's variables link map and its DWARF (3rd party is external) but embedded instrumentation and tools that are inserted into the processes address space with something like dyninst (1st party) don't have similar functions. 

So when you are working on a tools application keep 1st party tooling in mind. For this case, having a tool interface which allows us to find all the link maps and be notified when things change would be good. 

If Infinity + glibc is going to be the solution, how do we:
1) find the Infinity ELF notes from inside the application
2) Execute the DWARF expression to find the head of the link maps and iterate through them.
3) Trigger off of events in the dynamic linker when we inside the context of the process so that we can notice changes in the link map.

Alternatively if Infinity is only a 3rd party solution we should have a supported 1st party tools interface for the dynamic linker. Dyninst and by extension userspace systemtap can already find and trigger off of SDT markers. If there were functions in the dynamic linker which provided functions equivalent to libthread.db that allowed us to iterate through the link maps then we'd probably have the 1st party debugger thing covered.
Comment 5 Ben Woodard 2017-02-06 19:41:10 EST
LLNL requests that this bug be made public. They have collaborators at other organizations around the world that are also needing this functionality and they are collaborating on exascale tools. They want this open.

I have reviewed the comments so far and feel that there is nothing confidential in there.

Note You need to log in before you can comment on or make changes to this bug.