Hi,
TL;DR: Enabling these sanitizers yields absolute paths in .rodata. I’d like to try to address that.
I’m a C developer in a large project environment, and on behalf of the people setting up the CI I’m investigating how results from previous runs could be cached. The preferred solution right now is to look at the build-id, since that work is already done. That approach works if I compile with GCC or Clang, with or without debug info, using the proper flags for reproducible builds.
Also should there be a need to share a locally built version with asan, prehaps looking for debug information in a lab outside of the organisation, shareing of that absolut path might inadvertently be in violation of GDPR.
I’ve mostly been looking at ASan, and from my testing even a “hello world” program still ends up with absolute paths in .rodata. As far as I understand, neither GCC nor Clang inspects .rodata.
Being new to LLVM, I’d like to understand whether there is a good place in LLVM where this could be addressed. I’m just guessing here based on a high-level view of LLVM, but one possibility could be in the frontend where the compiler emits the absolute path used by the sanitizers, or perhaps some kind of post-audit pass that rewrites the absolute paths.