sanitizers: Fix tests/ui/sanitize/leak.rs fails on

[rcvalle]

Fix #111073 by checking if -Zexport-executable-symbols is passed when LeakSanitizer is enabled.

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in tests/ui/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

[rcvalle]

r? @tmiasko

[rustbot]

Some changes occurred in tests/codegen/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

[rcvalle]

cc @compiler-errors

[rcvalle]

@compiler-errors for context: #123617 (comment)

[tmiasko]

Can you describe the motivation behind this change?

Is it just a workaround for #111073? I think the actual issue is in sanitizer runtime and should be fixed there. In particular the interceptor for free works incorrectly when invoked with free(NULL) during initialization:

https://github.com/llvm/llvm-project/blob/332e6f86c50218ce60cafc9bf6d38d907da535ea/compiler-rt/lib/lsan/lsan_interceptors.cpp#L79-L84

For some reason, dynamic loader happens to call free(NULL) in one scenario but not in the other ...

[rcvalle]

This would be a fix for Clang linking the sanitizer runtimes with --dynamic-list=... or --export-dynamic. Is this related to the free(NULL) interception during initialization? Is the later caused by the former?

[tmiasko]

With regards to #111073, while --export-dynamic and -Zexport-executable-symbols avoids the issue for some reason, the interaction is unrelated to the root cause of the problem. Anyway, this should be already fixed in lsan runtime.

From your answer it is still not clear for me if the motivation for this change is limited to #111073 or attempts to replicate clang behavior more generally. If the latter can you describe why is it necessary? What is the problem and how does this change address it?

Additionally, this approach introduces dependency on another unstable feature which would block proposed stabilization.

[rcvalle]

If the Clang linking the sanitizer runtimes with --dynamic-list=... or --export-dynamic isn't a separate issue, and just worked around the free(NULL) interception during initialization for unknown reasons, I think we can close this if it's not needed.

[tmiasko]

clang exporting sanitizer interface with --dynamic-list makes it possible to load dynamic objects using dlopen that refer to sanitizer interface. The fact that rustc doesn't do that is definitely an issue.

At the moment, -Zexport-executable-symbols is no solution for this problem. The current implementation is incomplete - it doesn't add any symbols to dynamic symbol table. It is also unaware of sanitizer interface and so wouldn't export it.

To address that problem I would suggest following clang strategy. Add necessary linker flags automatically when sanitizers are enabled (as opposed to requiring end user to enable additional options manually as proposed here).