In a previous change I added a shim for fork(), but when compiled from InstrProfiling.c, the
required header file was not included, so pid_t was undefined. This change adds that include.
Summary:
Synchronize the function definition with the LLVM documentation.
https://llvm.org/docs/Atomics.html#libcalls-atomic
GCC also returns bool for the same atomic builtin.
Reviewers: theraven
Reviewed By: theraven
Subscribers: theraven, dberris, jfb, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79845
Fixes PR45673
The commit 9180c14fe4 (D76206) resolved only a part of the problem
of concurrent .gcda file creation. It ensured that only one process
creates the file but did not ensure that the process locks the
file first. If not, the process which created the file may clobber
the contents written by a process which locked the file first.
This is the cause of PR45673.
This commit prevents the clobbering by revising the assumption
that a process which creates the file locks the file first.
Regardless of file creation, a process which locked the file first
uses fwrite (new_file==1) and other processes use mmap (new_file==0).
I also tried to keep the creation/first-lock process same by using
mkstemp/link/unlink but the code gets long. This commit is more
simple.
Note: You may be confused with other changes which try to resolve
concurrent file access. My understanding is (may not be correct):
D76206: Resolve race of .gcda file creation (but not lock)
This one: Resolve race of .gcda file creation and lock
D54599: Same as D76206 but abandoned?
D70910: Resolve race of multi-threaded counter flushing
D74953: Resolve counter sharing between parent/children processes
D78477: Revision of D74953
Differential Revision: https://reviews.llvm.org/D79556
In a big-endian .gcda file, the first four bytes are "gcda" instead of "adcg".
All 32-bit values are in big-endian.
With this change, libclang_rt.profile can hopefully produce gcov
compatible output.
D49132 is partially correct. For 64-bit values, the lower 32-bit part comes
before the higher 32-bit part (in a little-endian manner).
For 32-bit values, libgcov reads/writes 32-bit values in native endianness.
gcov 9 (r264462) started to use GCOV_TAG_OBJECT_SUMMARY. Before,
GCOV_TAG_PROGRAM_SUMMARY was used.
libclang_rt.profile should emit just one tag according to the version.
Another bug introduced by rL194499 is that the wrong runcount field was
selected.
Fix the two bugs so that gcov can correctly decode "Runs:" from
libclang_rt.profile produced .gcda files, and llvm-cov gcov can
correctly decode "Runs:" from libgcov produced .gcda files.
Summary:
Fix hwasan allocator not respecting the requested alignment when it is
higher than a page, but still within primary (i.e. [2048, 65536]).
Reviewers: pcc, hctim, cryptoad
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79656
Create a sanitizer_ptrauth.h header that #includes <ptrauth> when
available and defines just the required macros as "no ops" otherwise.
This should avoid the need for excessive #ifdef'ing.
Follow-up to and discussed in: https://reviews.llvm.org/D79132
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D79540
Defaulting to -Xclang -coverage-version='407*' makes .gcno/.gcda
compatible with gcov [4.7,8)
In addition, delete clang::CodeGenOptionsBase::CoverageExtraChecksum and GCOVOptions::UseCfgChecksum.
We can infer the information from the version.
With this change, .gcda files produced by `clang --coverage a.o` linked executable can be read by gcov 4.7~7.
We don't need other -Xclang -coverage* options.
There may be a mismatching version warning, though.
(Note, GCC r173147 "split checksum into cfg checksum and line checksum"
made gcov 4.7 incompatible with previous versions.)
rL144865 incorrectly wrote function names for GCOV_TAG_FUNCTION
(this might be part of the reasons the header says
"We emit files in a corrupt version of GCOV's "gcda" file format").
rL176173 and rL177475 realized the problem and introduced -coverage-no-function-names-in-data
to work around the issue. (However, the description is wrong.
libgcov never writes function names, even before GCC 4.2).
In reality, the linker command line has to look like:
clang --coverage -Xclang -coverage-version='407*' -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data
Failing to pass -coverage-no-function-names-in-data can make gcov 4.7~7
either produce wrong results (for one gcov-4.9 program, I see "No executable lines")
or segfault (gcov-7).
(gcov-8 uses an incompatible format.)
This patch deletes -coverage-no-function-names-in-data and the related
function names support from libclang_rt.profile
https://reviews.llvm.org/D63616 added `-fsanitize-coverage-whitelist`
and `-fsanitize-coverage-blacklist` for clang.
However, it was done only for legacy pass manager.
This patch enable it for new pass manager as well.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D79653
Summary:
This is necessary to handle calls to free() after __hwasan_thread_exit,
which is possible in glibc.
Also, add a null check to GetCurrentThread, otherwise the logic in
GetThreadByBufferAddress turns it into a non-null value. This means that
all of the checks for GetCurrentThread() != nullptr do not have any
effect at all right now!
Reviewers: pcc, hctim
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79608
Summary: The new pass manager symbolizes the location as ~Simple instead of Simple::~Simple.
Reviewers: rnk, leonardchan, vitalybuka
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79594
Summary:
When forking in several threads, the counters were written out in using the same global static variables (see GCDAProfiling.c): that leads to crashes.
So when there is a fork, the counters are resetted in the child process and they will be dumped at exit using the interprocess file locking.
When there is an exec, the counters are written out and in case of failures they're resetted.
Reviewers: jfb, vsk, marco-c, serge-sans-paille
Reviewed By: marco-c, serge-sans-paille
Subscribers: llvm-commits, serge-sans-paille, dmajor, cfe-commits, hiraditya, dexonsmith, #sanitizers, marco-c, sylvestre.ledru
Tags: #sanitizers, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D78477
When reporting diagnostics from ASan's (and other sanitizer's) signal
handlers we should strip the "invalid signature" bit before printing
addresses. This makes the report less confusing and let's the user
focus on the real issue.
rdar://62615826
Reviewed By: kubamracek, delcypher
Differential Revision: https://reviews.llvm.org/D79132
Summary:
Currently, realloc is marked as "discard" in done_abilist.txt. As discussed in PR#45583, this is probably not the expected behavior; a custom wrapper seems to be required. Since this wrapper has not been implemented yet, realloc should not be in the done_abilist.txt file so that a warning is displayed when it is called.
Reviewers: kcc, pcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78379
It looks like some bots are failing with os log not giving any
output. This might be due to the system under test being heavy
load so the 2 minute window might not be large enough. This
patch makes the window larger in the hope that this test will
be more reliable.
rdar://problem/62141527
Summary:
Implement pattern initialization of memory (excluding the secondary
allocator because it already has predictable memory contents).
Expose both zero and pattern initialization through the C API.
Reviewers: pcc, cryptoad
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79133
Summary:
If this is called before the malloc call in a thread (or in the whole
program), the lazy initialization of the allocation can overwrite
Options.
Reviewers: pcc, cryptoad
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79130
Newer iOS SDK introduce accessors to retrieve the register values
(arm_thread_state64_get_*) and disallows direct access to fields. If
arm_thread_state64_get_sp is defined, the accessors are available.
Summary: Fixes an ABI violation in the trampoline code for AArch64 that causes the indirect result register to get overwritten if the XRay handler function is complex enough to use it.
Reviewers: MaskRay, dberris, johnislarry
Subscribers: kristof.beyls, danielkiss, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78596
This is the first patch in a series to add support for the AVR target.
This patch includes changes to make compiler-rt more target independent
by not relying on the width of an int or long.
Differential Revision: https://reviews.llvm.org/D78662
Summary:
Following up the discussion on D77638 (and following rGd6cfed6060c283dc4a6bf9ca294dcd732e8b9f72
as example), defining `__sanitizer_cov_bool_flag_init` as the weak interface
functions in various compiler-rt/ files.
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: dberris, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D77857
Follow-up of D78082 and D78590.
Otherwise, because xray_instr_map is now read-only, the absolute
relocation used for Sled.Function will cause a text relocation.
Follow-up of D78082 (x86-64).
This change avoids dynamic relocations in `xray_instr_map` for ARM/AArch64/powerpc64le.
MIPS64 cannot use 64-bit PC-relative addresses because R_MIPS_PC64 is not defined.
Because MIPS32 shares the same code, for simplicity, we don't use PC-relative addresses for MIPS32 as well.
Tested on AArch64 Linux and ppc64le Linux.
Reviewed By: ianlevesque
Differential Revision: https://reviews.llvm.org/D78590
Summary: Switch to pc-relative lookup of the xray handler function to avoid text relocations.
Reviewers: MaskRay, dberris, johnislarry
Subscribers: kristof.beyls, danielkiss, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78595
Summary: We load multiple copies of the trampolines into memory when instrumenting DSOs. Hidden visibility prevents conflicts in this scenario.
Reviewers: MaskRay, dberris, johnislarry
Subscribers: #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78593
Summary:
While working on rdar://problem/62083617 I noticed this call was
missing.
This is a no-op for all platforms except Darwin. For Darwin this
means the `use_xnu_fast_mmap` flag is initialized as it was intended
when using UBSan in standalone mode.
Reviewers: vitalybuka, vsk, kubamracek, yln, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78532
Summary:
This fixes symbolization in Standalone UBSan mode for the Darwin simulators.
861b69faee (rdar://problem/58789439) tried to fix
symbolization for all sanitizers on Darwin simulators but unfortunately it only
fixed the problem for TSan.
For UBSan in standalone mode the fix wasn't sufficient because UBSan's
standalone init doesn't call `Symbolizer::LateInitialize()` like ASan
and TSan do. This meant that `AtosSymbolizerProcess::LateInitialize()`
was never being called before
`AtosSymbolizerProcess::StartSymbolizerSubprocess()` which breaks an
invariant we expect to hold.
The missing call to `Symbolizer::LateInitialize()` during UBSan's
standalone init seems like an accidently omission so this patch simply
adds it.
rdar://problem/62083617
Reviewers: vitalybuka, kubamracek, yln, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D78530
* Changing source lines seems to cause us to hit rdar://problem/62132428.
* Even if I workaround the above issue sometimes the source line in the dylib reported by atos is off by one.
It's simpler to just disable the test for now.
rdar://problem/61793759
Alex Lorenz