Future directions for the dynamic linker auditing (LD_AUDIT) interface

[Jonathon Anderson]

I concur with the proposition to prototype a shim out downstream, speaking for HPCToolkit there are multiple advantages to pooling our efforts. If Glibc decides to go "one auditor only" we will have troubles if the shim is inconsistently adopted or conflicting implementations emerge, but if the major users/admirers of LD_AUDIT are informed (hi everyone) I think we can prevent this.

However, I would not hastily assume the current LD_AUDIT is sufficient to support all our use cases. The conversations around recursive dlopen() and static TLS allocation stand out in my mind as "bugs" that could take dramatic changes to the auditor interface to properly resolve. Even the lack of self-monitoring callbacks mentioned in BZ#31992 could pose a challenge. There are certainly others, both found and yet to be discovered.

What will the Glibc stance for these cases be, i.e. will upstream Glibc accept further (possibly breaking) improvements to LD_AUDIT before the "next-generation" API has been prototyped, proven, and merged?

Thanks,\
-Jonathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241122/e843078d/attachment-0001.htm>
-------------- next part --------------
An embedded message was scrubbed...
From: Carlos O'Donell <carlos@redhat.com>
Subject: Re: Future directions for the dynamic linker auditing (LD_AUDIT) interface
Date: Fri, 22 Nov 2024 13:07:04 -0500
Size: 14975
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241122/e843078d/attachment-0001.eml>