Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppleClang: TSAN prefers UBSAN_OPTIONS if available #1843

Open
godexsoft opened this issue Jan 23, 2025 · 2 comments
Open

AppleClang: TSAN prefers UBSAN_OPTIONS if available #1843

godexsoft opened this issue Jan 23, 2025 · 2 comments

Comments

@godexsoft
Copy link

I have a simple script that sets UBSAN_OPTIONS, TSAN_OPTIONS, etc. all at once to specify log_path for each sanitizer.
On Linux/gcc everything is as expected but when I compile with TSAN using AppleClang on MacOSX it appears that TSAN takes the log_path from UBSAN_OPTIONS instead of TSAN_OPTIONS if both are set. If only TSAN_OPTIONS are set then everything works as expected. This leads to ThreadSanitizer output land in TestName.ubsan.log.[PID].

@Enna1
Copy link

Enna1 commented Jan 24, 2025

See https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/tsan/rtl/tsan_flags.cpp#L54,

IIRC this is compatible with other sanitizers, e.g. ASan.

@godexsoft
Copy link
Author

So my assumption from glancing at the code you pointed me to is that on AppleClang TSAN is built with support for UBSAN but on my Linux it happens to be not, hence the difference. Is that what you mean @Enna1 ?
One thing I don't understand is why the implementation overrides my TSAN options with UBSAN options. It would make more sense if UBSAN options are parsed first and then overridden by TSAN options if they are available. Then further refined by command line options if needed. Would you say this is still a bug?
I'm ok to ignore this since in my use case I will never have the code built nor ran with more than one sanitiser at a time but I feel like the logic is backwards in the current implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants