Bug 1292563

Summary:	[LLNL 7.5 FEAT] Provide API to access all link maps, including those from dlmopen (gdb)
Product:	Red Hat Enterprise Linux 7	Reporter:	Ben Woodard <woodard>
Component:	gdb	Assignee:	Gary Benson <gbenson>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-tools-bugs
Severity:	high	Docs Contact:
Priority:	high
Version:	7.3	CC:	ashankar, codonell, dsmith, fweimer, gbenson, gdb-bugs, jan.kratochvil, legendre1, mnewsome, pfrankli, qe-baseos-tools-bugs, sergiodj, tgummels, woodard
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	7.5
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:	1265827	Environment:
Last Closed:	2019-06-05 19:20:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 1 Ben Woodard 2015-12-17 19:32:51 UTC

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 20:39:45 UTC

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-07 00:41:10 UTC

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.

Comment 8 David Smith 2019-06-05 19:20:21 UTC

I'm going to close this one. At this point in RHEL7's life cycle, new features aren't really allowed (without strong business justification). Plus, this work still hasn't made it upstream. By the time it does make it upstream, I also doubt backporting this functionality to the version of gdb in RHEL7 will be possible - the code bases will have changed too much.