It's used in asan_test.cc also on Windows, and my build was failing
with:
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:549:28: error: unknown type name 'jmp_buf'
NOINLINE void LongJmpFunc1(jmp_buf buf) {
^
C:/src/llvm/projects/compiler-rt/lib/asan/tests/asan_test.cc:569:10: error: unknown type name 'jmp_buf'
static jmp_buf buf;
^
I couldn't find what changed to make this not work anymore, but this should fix
it.
llvm-svn: 303273
Summary:
This required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.
Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.
1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.
Reviewers: alekseyshl, kubamracek
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33215
llvm-svn: 303262
This inclusion is needed to fix the ARM build. The int_lib.h include is
slightly ugly, but allows us to use the `AEABI_RTABI` macro to decorate
the CC for the functions.
llvm-svn: 303190
These actually may change calling conventions. We cannot simply provide
function aliases as the aliased function may have a different calling
convention. Provide a forwarding function instead to permit the
compiler to synthesize the calling convention adjustment thunk.
Remove the `ARM_EABI_FNALIAS` macro as that is not safe to use.
Resolves PR33030!
llvm-svn: 303188
Summary: Use __linux__ to check for Linux and bring back the check for __GNU__.
Reviewers: echristo, krytarowski, compnerd, rengolin
Reviewed By: krytarowski
Subscribers: phosek, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D33219
llvm-svn: 303131
Some build targets (e.g. i686) have aliased names (e.g. i386). We would
get multiple definitions previously and have the linker arbitrarily
select a definition on those aliased targets. Make this more
deterministic by checking those aliases.
llvm-svn: 303103
Add a lit substitution (I chose %gmlt) so that only stack trace tests
get debug info.
We need a lit substition so that this expands to -gline-tables-only
-gcodeview on Windows. I think in the future we should reconsider the
need for -gcodeview from the GCC driver, but for now, this is necessary.
llvm-svn: 303083
Summary:
With rL279771, SizeClassAllocator64 was changed to accept only one template
instead of 5, for the following reasons: "First, this will make the mangled
names shorter. Second, this will make adding more parameters simpler". This
patch mirrors that work for SizeClassAllocator32.
This is in preparation for introducing the randomization of chunks in the
32-bit SizeClassAllocator in a later patch.
Reviewers: kcc, alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D33141
llvm-svn: 303071
This fixes tests that use debug info to check ubsan stack traces. One
was XFAILd on Windows and the other was actively failing for weeks.
llvm-svn: 302924
These tests don't fail consistently in all cases, but they
fail most of the time on the buildbots. Mark as UNSUPPORTED for now to
avoid buildbots failing due to XPASS.
llvm-svn: 302920
Our theory is that reserving large amounts of shadow memory isn't
reliable on Win7 and earlier NT kernels. This affects the
clang-x64-ninja-win7 buildbot, which uses Windows 7.
llvm-svn: 302917
Summary:
Sanitizer procmaps uses dyld apis to iterate over the list of images
in the process. This is much more performan than manually recursing
over all of the memory regions in the process, however, dyld does
not report itself in the list of images. In order to prevent reporting
leaks from dyld globals and to symbolize dyld functions in stack traces,
this patch special-cases dyld and ensures that it is added to the
list of modules.
This is accomplished by recursing through the memory map of the process
until a dyld Mach header is found. While this recursion is expensive,
it is run before the full set of images has been loaded in the process,
so only a few calls are required. The result is cached so that it never
needs to be searched for when the full process memory map exists, as this
would be incredibly slow, on the order of minutes for leak sanitizer with
only 25 or so libraries loaded.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32968
llvm-svn: 302899
thread_get_register_pointer_values handles the redzone computation
automatically, but is marked as an unavailable API function. This
patch replicates its logic accounting for the stack redzone on
x86_64.
Should fix flakiness in the use_stack_threaded test for lsan on darwin.
llvm-svn: 302898
This is a follow-up to r302787, which broke MemorySanitizer.ICmpRelational.
MSan is now reporting a false positive on the following test case:
TestForNotPoisoned((poisoned(-1, 0x80000000U) >= poisoned(-1, 0U)))
, which is sort of anticipated, because we're approximating the comparison
with an OR of the arguments' shadow values.
llvm-svn: 302887
We only have an implementation in x86_64 that works for the
patching/unpatching and runtime support (trampolines).
Follow-up to D30630.
llvm-svn: 302873
Summary:
This change implements support for the custom event logging sleds and
intrinsics at runtime. For now it only supports handling the sleds in
x86_64, with the implementations for other architectures stubbed out to
do nothing.
NOTE: Work in progress, uploaded for exposition/exploration purposes.
Depends on D27503, D30018, and D33032.
Reviewers: echristo, javed.absar, timshen
Subscribers: mehdi_amini, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D30630
llvm-svn: 302857
Summary:
The reasoning behind this change is twofold:
- the current combined allocator (sanitizer_allocator_combined.h) implements
features that are not relevant for Scudo, making some code redundant, and
some restrictions not pertinent (alignments for example). This forced us to
do some weird things between the frontend and our secondary to make things
work;
- we have enough information to be able to know if a chunk will be serviced by
the Primary or Secondary, allowing us to avoid extraneous calls to functions
such as `PointerIsMine` or `CanAllocate`.
As a result, the new scudo-specific combined allocator is very straightforward,
and allows us to remove some now unnecessary code both in the frontend and the
secondary. Unused functions have been left in as unimplemented for now.
It turns out to also be a sizeable performance gain (3% faster in some Android
memory_replay benchmarks, doing some more on other platforms).
Reviewers: alekseyshl, kcc, dvyukov
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33007
llvm-svn: 302830
This breaks several tests because we don't always have
access to __cxa_guard functions
This reverts commit 45eb470c3e9e8f6993a204e247c33d4092237efe.
llvm-svn: 302693
Summary:
This bug is caused by the incorrect handling of return-value registers.
According to OpenPOWER 64-Bit ELF V2 ABI 2.2.5, up to 2 general-purpose
registers are going to be used for return values, and up to 8 floating
point registers or vector registers are going to be used for return
values.
Reviewers: dberris, echristo
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33027
llvm-svn: 302691
Summary:
The test fails on PPC, because the address of a function may vary
depending on whether the "taker" shares the same ToC (roughly, in the
same "module") as the function.
Therefore the addresses of the functions taken in func-id-utils.cc may be
different from the addresses taken in xray runtime.
Change the test to be permissive on address comparison.
Reviewers: dberris, echristo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33026
llvm-svn: 302686
Disable building enable_execute_stack.c for targets that do not have
support for mprotect().
Differential Revision: https://reviews.llvm.org/D33018
llvm-svn: 302680
Summary:
Sanitizer procmaps uses dyld apis to iterate over the list of images
in the process. This is much more performan than manually recursing
over all of the memory regions in the process, however, dyld does
not report itself in the list of images. In order to prevent reporting
leaks from dyld globals and to symbolize dyld functions in stack traces,
this patch special-cases dyld and ensures that it is added to the
list of modules.
This is accomplished by recursing through the memory map of the process
until a dyld Mach header is found. While this recursion is expensive,
it is run before the full set of images has been loaded in the process,
so only a few calls are required. The result is cached so that it never
needs to be searched for when the full process memory map exists, as this
would be incredibly slow, on the order of minutes for leak sanitizer with
only 25 or so libraries loaded.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32968
llvm-svn: 302673
Some configuration (for instance default docker ubuntu images) uses
a default empty and invalid /etc/fstab configuration file. It makes
any call to getmntent return NULL and it leads to failures on
Msan-aarch64{-with-call}-Test/MemorySanitizer.getmntent{_r}.
This patch fixes it by creating a temporary file with some valid
entries (although not valid for the system) to use along with
setmntent/getmntent.
llvm-svn: 302639
By default glibc writes its diagnostics directly to tty so the `2>&1 |`
redirection in the test doesn't catch the *** stack smashing detected ***
message, which in turn breaks printing the lit's progress bar. By defining
the LIBC_FATAL_STDERR_ environment variable we force glibc to direct
diagnostic messages to stderr.
Differential Revision: https://reviews.llvm.org/D32599
llvm-svn: 302628