Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.
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.