This moves the platform-specific parameter logic from asan into
lsan_common.h to lsan can share it.
|73 ↗||(On Diff #292339)|
sanitizer allocator is used by msan, scudo, hwasan and upcoming D87120
However asan can #include lsan
Please don’t do this. You’re adding a dependency between asan and lsan, and
making it impossible to support platforms without lsan.
It’s a layering violation. I guess you can hack it if you add a *very
minimal * “allocator for asan and/or lsan” in sanitizer common. That
wouldn’t be ideal (a header shared between only two Sanitizers, but at
least it would be in the right place.
The source dependency already exists throughout the asan code, which unconditionally includes lsan headers.
There is no change to the fact that systems without lsan support work fine. It's already the case that #if CAN_SANITIZE_LEAKS is checked throughout the asan code to control whether it assumes lsan support.
This change does not any new interdependencies. The only reliance on lsan is that it's in the compiler-rt source tree, as before.
The purpose of the change is to fix the lsan allocator configuration, which is practically unusable for aarch64.
It was clear that nobody had really maintained the lsan configurations and that the asan configurations were better-maintained and the proven settings for each platform. So everyone agreed that sharing the same settings between asan and lsan was the right thing to do. It seems very error-prone for future maintenance if this is done by copying the code. That's what happened before, and then someone changed the asan configuration settings to actually work well on more platforms and neglected to update the lsan configurations. We know that will happen again next time there is a need to change the asan configurations, so it seems unwise to merely update the copy rather than share the code, especially when it's so trivial to do so and there are no new interdependencies actually introduced.