ndk
ndk copied to clipboard
[FR] clang compiler driver should reject unsupported sanitizers
Description
Getting this with -fsanitize=memory
:
ld.lld: error: cannot open <my_ndk_r26>/toolchains/llvm/prebuilt/linux-x86_64/lib/clang/17/lib/linux/libclang_rt.msan-aarch64-android.a: No such file or directory
Not sure if it is bug or conscious choice for r26, so opening as FR.
Can we have msan rt lib in NDK?
msan is not one of the supported sanitizers on Android. See https://github.com/google/sanitizers/issues/1381.
If you're debugging memory initialization issues, you can use the options in https://source.android.com/docs/security/test/memory-safety/zero-initialized-memory#zero-initialized-userspace to zero|patten
initialize the stack and zero-initialize the heap.
(see also https://developer.android.com/ndk/guides/hwasan which is the main thing we use within Android to find memory errors --- i certainly do all my development with hwasan enabled.)
@pirama-arumuga-nainar @enh-google Thanks you for answers/recommendations!
Then, if msan is not supported, should NDK maybe give some explicit error about it? I can imagine that you'll periodically get tickets from impatient users (like I am :)). I guess that you see no point in tweaking clang driver to reject -fsanitize=memory
. If so - can we maybe have libclang_rt.msan-XXX-android.a
in the NDK in a form of a linker script that aborts process with some message, like maybe:
ASSERT(0, "msan is not supported, consider other alternatives")
I haven't tried this but assume it should work as NDK already has supplemental linker scripts for libc++. Obviously this will fail build quite late and rejecting CLI option at driver level would be more user-friendly but it is still an option that might be easier for you to implement.
if msan is not supported, should NDK maybe give some explicit error about it?
It rarely has much to do with what we want. It's about what LLVM will accept. They might accept that? @pirama-arumuga-nainar?
(@appujee filed an internal bug that mentions that iOS/macOS already has an equivalent check.)
That's promising then. I'll retitle this bug for that.
Is ASAN still not supported? I just burned a good amount of time on this, because:
This page suggests that it is supported, except for arm64 platform development (I'm using the 16k pages emulator).
This page also says it's supported.
This page says it's not supported, but still documents how to use it and does not say it is broken.
This page says hwasan is supported only for arm64.
Is there no longer any way to do msan in any form on an emulator?
Maybe as a part of this bug, the docs I found could be updated as well?
i don't think any of those is actually incorrect ... i'm guessing you didn't spot the distinction between source.android.com being for OS development and developer.android.com being for app development?
i think the note on the app development pages saying "you're in the wrong place for OS development" is good, and we should probably add the opposite note on the OS development page...
(internal change https://critique.corp.google.com/cl/627739981 adds a note to the s.a.c documentation.)
The only one that's wrong at first glance is https://github.com/google/sanitizers/wiki/AddressSanitizerOnAndroid/01f8df1ac1a447a8475cdfcb03e8b13140042dbd#running-with-wrapsh-recommended, but that's because you're reading an old version of the doc. Remove the SHA from the URL to see the up-to-date version: https://github.com/google/sanitizers/wiki/AddressSanitizerOnAndroid/. That redirects to the NDK's doc, which says deprecated.
In the future, please open a discussion for this sort of question.