Also enable on X86_64.
The directory would change during the test execution. This should not
necessarily prevent us from indexing a directory (a user might
potentially do that if they specify a parent directory of the actual
symbols directory, and change unrelated files).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125143
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
Tested on an example callstack with misplaced binaries from Android.
Tested Regex against callstack without Build ID to confirm it still works.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D123437
Aligned new does not require size to be a multiple of alignment, so
memalign is the correct choice instead of aligned_alloc.
Fixes false reports for unaligned sizes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D119161
Aligned new does not require size to be a multiple of alignment, so
memalign is the correct choice instead of aligned_alloc.
Fixes false reports for unaligned sizes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D119161
Fixes segfaults on x86_64 caused by instrumented code running before
shadow is set up.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D118171
Fixes a false positive that occurs when a user-implemented memmove is
instrumented by HWASan.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D118180
Google-signed apexes appear on Android build servers' symbol files as
being under /apex/com.google.android.<foo>/. In reality, the apexes are
always installed as /apex/com.android.<foo>/ (note the lack of
'google'). In order for local symbolization under hwasan_symbolize to
work correctly, we also try the 'google' directory.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D114919
It should be NFC, as they already intercept pthread_create.
This will let us to fix BackgroundThread for these sanitizerts.
In in followup patches I will fix MaybeStartBackgroudThread for them
and corresponding tests.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D114935
Verified no diff exist between previous version, new version python 2, and python 3 for an example stack.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D114404
Since glibc 2.34, dlsym does
1. malloc 1
2. malloc 2
3. free pointer from malloc 1
4. free pointer from malloc 2
These sequence was not handled by trivial dlsym hack.
This fixes https://bugs.llvm.org/show_bug.cgi?id=52278
Reviewed By: eugenis, morehouse
Differential Revision: https://reviews.llvm.org/D112588
GCC introduced `__attribute__((mode(unwind_word)))` to work around
Cell Broadband Engine SPU (which was removed from GCC in 2019-09),
which is irrelevant to hwasan.
_Unwind_GetGR/_Unwind_GetCFA from llvm-project/libunwind don't use unwind_word.
Using _Unwind_Word can lead to build failures if libunwind's unwind.h is
preferred over unwind.h in the Clang resource directory (e.g. built with GCC).
I recently spent some extra time debugging a false positive because I
didn't realize the "real" tag was in the short granule. Adding the
short tag here makes it more obvious that we could be dealing with a
short granule.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D112949
Add a default "/" prefix to the symbol search path in the
symbolization script. Without this, the binary itself is not considered
a valid source of symbol info.
Differential Revision: https://reviews.llvm.org/D111840
1. Include <cet.h> in sanitizer_common/sanitizer_asm.h, if it exists, to
mark Intel CET support when Intel CET is enabled.
2. Define _CET_ENDBR as empty if it isn't defined.
3. Add _CET_ENDBR to function entries in assembly codes so that ENDBR
instruction will be generated when Intel CET is enabled.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D111185
This reverts commit fdf4c03522.
Breaks macOS bots, e.g. https://crbug.com/1257863.
Still figuring out if this is actually supported on macOS. Other places
that include <cet.h> only do so on Linux.
1. Include <cet.h> in sanitizer_common/sanitizer_asm.h to mark Intel CET
support when Intel CET is enabled.
2. Add _CET_ENDBR to function entries in assembly codes so that ENDBR
instruction will be generated when Intel CET is enabled.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D111185
Specifying .global and .weak causes a compiler warning:
warning: __sigsetjmp changed binding to STB_WEAK
Specifying only .weak should have the same effect without causing a
warning.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D110178
Some setjmp calls within libc cannot be intercepted while their matching
longjmp calls can be. This causes problems if our setjmp/longjmp
interceptors don't use the exact same format as libc for populating and
reading the jmp_buf.
We add a magic field to our jmp_buf and populate it in setjmp. This
allows our longjmp interceptor to notice when a libc jmp_buf is passed
to it.
See discussion on https://reviews.llvm.org/D109699 and
https://reviews.llvm.org/D69045.
Fixes https://github.com/google/sanitizers/issues/1244.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D109787
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
Fixes a regression when the allocator is disabled, and a dirty
allocation is re-used. This only occurs when the allocator is disabled,
so a test-only fix, but still necessary.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108650
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
Florian Mayer