Let’s say the default libc++.so is in path/to/lib/x86_64-unknown-linux-gnu and you want to build asan-instrumented libc++.so and place it in path/to/lib/x86_64-unknown-linux-gnu/asan/.
You can specify -fsanitize=address -Lpath/to/lib/x86_64-unknown-linux-gnu/asan. It’s manual but it does affect driver -lc++.
Let’s say we also build asan/ubsan-instrumented libc++.so. The user can specify -fsanitize=address,undefined -Lpath/to/lib/x86_64-unknown-linux-gnu/ubasan.
For certain system libraries, you probably want to use -L anyway.
The fact that driver change may overlap with Clang’s experimental multilib support makes me nervous. [RFC] Multilib
This mechanism is currently BareMetal only. My idea is that it is generic and can be extended to Gnu.cpp. Users may build the sets of instrumented libc++.so (or libc++.a) they want and specify a configuration file, instead of relying on hard-coded driver logic (which I supposed you are trying to do; and I hope that we can hold off doing it).