Description of problem:
At LLNL there are computational physicists who design interesting data sets that explore interest physics but who are not computer scientists. They run applications provided to them by computer scientists whose job is to implement the physics and make the binaries. The people who write and compile the programs are different than the people who generally run them.
The tools team at the lab generally would like to work the the computer scientists to provide tools that do various things. Several of their tools end up being implementable as audit libraries. One example is spindle http://computation.llnl.gov/projects/spindle another example is the common practice of wrapping library functions. In static cases wrapping can be done with LD_PRELOAD but to generalize the capability making it into an audit library that replaces the symbol and then calls the original is more effective.
In these cases the tools people want to work with the computer scientists and have them simply link in a tool library which is an audit library. An interface something like:
ld -faudit audit_lib.so foo.o bar.o -l libfoo.so ... -o exe
So that an original computer scientist can permanently have an audit lib loaded when the executable is run as if it were run like:
LD_AUDIT=audit_lib.so exe args...
ld.so would see the DT_NEEDED with some magic flag somewhere which says that this should be loaded as an audit library and dlmopened first and called the same way and the same times as if it were specified in the LD_AUDIT environment variable. This way it can replace the functions the way that spindle does or wrap the functions as needed.
This would require a new option to ld to specify the audit libraries to be linked in. That is more of a binutils feature. However, it would also require a change to ld.so which is part of glibc.
Additional info:
1) multiple audit libraries may be specified.
2) it is important that debuggers are able to debug code that is brought in through these audit libraries. Thus tools like GDB need to be able to find the link maps and enumerate the symbols in libraries which are brought in this way.
Suppose that a program uses this feature to install an audit module. What should happen if the program is run with a glibc version which does not support this feature?
Should the program fail to start, or just run without loading the audit module?
I am checking with the customer's tools team but I'm inclined to say that it it doesn't matter. Either way is fine. The use case almost precludes this from happening. So it is something highly hypothetical.
The semantics of this solution are not yet pinned down for RHEL 7.8, and since RHEL 7 is entering Maintenance Phase 1 at the end of 2019 I'm going to move this bug to RHEL 8 where we can continue to use this to track requests from LLNL.