After D143438 there is no point in this check as the size will never 0. Also this keeps it consistent with ASAN where there is not size check in LsanMetadata::allocated.
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D143442
Without this, if hardening measures like FORTIFY_SOURCE are are in
/etc/clang/*.cfg, many sanitizer tests will die before the sanitizer
can trap the problem being tested, because e.g. the _chk variants
of common functions will abort first.
This gets the number of failing tests down from 42->3 for me (and the
remaining 3 are unrelated).
See: 52ce6776cf98e993c6ec04ae54b52e1354fff917
See: 136f77805fd89cd30e69b3d1204fbf7efedd9a12
Closes: https://github.com/llvm/llvm-project/issues/60394
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D143322
The fix only affects Darwin, but to write the test I had to modify
the MemoryMappingLayout class which is used by all OSes,
to allow for mocking of image header (this change should be NFC). Hence no [Darwin] in the subject
so I can get more eyes on it.
While looking for a memory gap to put the shadow area into, the sanitizer code
scans through the loaded images, and for each image it scans through its
loader command to determine the occupied memory ranges.
While doing so, if the 'segment load' (kLCSegment) loader comand is encountered, the command scanning function
returns success (true), but does not decrement the command list iterator counter.
The result is that the function is called again and again, with the iterator counter
now being too high. The command scanner keeps updating the loader command pointer,
by using the command size field.
If the loop counter is too high, the command pointer
lands into unintended area ( beyond <header addr>+sizeof(mac_header64)+header->sizeofcmds ),
and result depends on the random content found there.
The random content interpreted as loader command might contain a large integer value in the
cmdsize field - this value is added to the current loader command pointer,
which might now point to an inaccessible memory address. It can occasionally result
in a crash if it happens to run beyond the mapped memory segment.
Note that when the area after the loader command list
contains zeros or small integers only, the loop will end normally and the problem
will go unnoticed. So it happened until now since having a some big value
after the header area, falling into command size field is a pretty rare situation.
The fix makes sure that the iterator counter gets updated when the segment load (kLCSegment)
loader command is found too, and in the same code location so the updates will always go together.
Undo the changes in the sanitizer_procmaps_mac.cpp to see the test failing.
rdar://101161047
rdar://102819707
Differential Revision: https://reviews.llvm.org/D142164
On 32-bit glibc>=2.34 systems using 64bit time_t build fails because
_FILE_OFFSET_BITS is undefined here but _TIME_BITS is still set to 64
Fixes
```
/usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed
only with _FILE_OFFSET_BITS=64"
| # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^
| 1 error generated.
```
Reviewed By: thesamesam, MaskRay
Differential Revision: https://reviews.llvm.org/D140812
For atomics metadata, we can make data race analysis more efficient by
entirely ignoring functions that include memory accesses but which only
access non-escaping (non-shared) and/or non-mutable memory. Such
functions will not be considered to be covered by "atomics" metadata,
resulting in the following benefits:
1. reduces "covered" metadata; and
2. allows data race analysis to skip such functions.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D143159
It's better and easier for us to just have threads contend against each
other in the tests if it's more than the maximum supported number of
hardware threads available.
Specifically, the recoverable test fails on Android because the
GTEST_SKIP in a called function, and it only properly works from the
TEST_* harness function. Android tests run on cuttlefish, which can be a
single core with two hyperthreads.
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D143221
For HWASAN this would be the tagged address. It is the same pointer when pointer tagging is not used. Coincidently this also fixes some test which rely on comparing pointers.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D143121
They were being initialized anyway, I believe, but the logic was a bit
convoluted for the Clang warnings to detect so we were getting "variable 'EBX'
may be uninitialized when used here" later on.
Older GNU assemblers generate R_X86_64_PC32 relocation against
defined non-weak global branch targets with default visibility. A
linker may issue an error when building a shared library. Add a local
alias, .Linterceptor_sigsetjmp, to __interceptor_sigsetjmp to avoid
R_X86_64_PC32 relocation for "jmp __interceptor_sigsetjmp" with older
GNU assemblers.
Fixes: https://github.com/llvm/llvm-project/issues/60426
Differential Revision: https://reviews.llvm.org/D142995
Loosen up the matching so that occasional cpu migrations don't break the
test. This showed up occasionally in internal testing.
Differential Revision: https://reviews.llvm.org/D143000
The orginal single folder layout produced libraries in the form:
lib/linux/<libname>-<archname>.a
That archname for Arm depended on whether you had hard or soft float.
This is sometimes shown as "arm" (soft) vs. "armhf" (hard).
If this is set in a triple we do it in the final portion, the ABI.
"gnueabi" for soft float, "gnueabihf" for hard float.
Meaning that the expected triple is:
arm-unknown-linux-gnueabihf
Not this:
armhf-unknown-linux-gnueabihf
For the per target layout I have decided to rely on the ABI portion
of the triple instead of the arch name used for the old layout
(doing that would produce the invalid triple above).
This means that building with triple:
armv8l-unknown-linux-gnueabihf
Will result in libraries in:
lib/arm-unknown-linux-gnueabihf/
And clang will now know to look for "arm" instead of "armv8l".
Meaning that we can share libraries between an armv8 and armv7 build
as we did with the previous layout. In addition to handling spelling
differences e.g. "armv8l" with an "l" on some Linux distros.
compiler-rt will autodetect that the "armhf" and/or "arm" architecture
can be built. We then replace the given triple's architecture with that.
Then if the triple's float ABI doesn't match, we change that. That new
triple is then used as the folder name.
If you select to build only the given triple, with COMPILER_RT_DEFAULT_TARGET_ONLY,
compiler-rt will not autodetect the architecture and for that I assume you
know what you're doing. In that case the library path will use the unomdified triple.
From what I can tell, this is how most large builds e.g Android and
Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb"
builds would end up doing this too.
Bare metal builds will not be using per target runtime dirs so they
remain as they were.
Depends on D139536
Reviewed By: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D140011
A lot of tests are disabled by using UNSUPPORTED. The plan is to remove UNSUPPORTED for tests that are fixed.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D142676
This broke the sanitizer tests on Mac, see e.g.
https://green.lab.llvm.org/green/job/clang-stage1-RA/32739/ and comment on the
code review.
> A lot of tests are disabled by using UNSUPPORTED. The plan is to remove UNSUPPORTED for tests that are fixed.
>
> Reviewed By: vitalybuka
>
> Differential Revision: https://reviews.llvm.org/D142676
This reverts commit f9a01630988716f1b52afe6727f34fe86c07c58a.
and follow-up commit bf47ffaa76fbda1ba96d41ee2681e45d2445be1e
(https://reviews.llvm.org/D142812).
A lot of tests are disabled by using UNSUPPORTED. The plan is to remove UNSUPPORTED for tests that are fixed.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D142676
In many cases, we can use an alias to avoid a symbolic relocations,
instead of using the public, interposable symbol. When the instrumented
function is in a COMDAT, we can use a hidden alias, and still avoid
references to discarded sections.
Previous versions of this patch allowed the compiler to name the
generated alias, but that would only be valid when the functions were
local. Since the alias may be used across TUs we use a more
deterministic naming convention, and add a ".local" suffix to the alias
name just as we do for relative vtables aliases.
https://reviews.llvm.org/rG20894a478da224bdd69c91a22a5175b28bc08ed9
removed an incorrect assertion on Mach-O which caused assertion failures in LLD.
We prevent duplicate symbols under ThinLTO + PGO + CFI by disabling
alias generation when the target function has MD_type metadata used in
CFI.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D137982
This patch remove xfail decorator from
builtins/Unit/trampoline_setup_test.c as it is passing on Windows/AArch64
nowz. It is being skipped in code with __clang__ not defined.
https://lab.llvm.org/buildbot/#/builders/120/builds/3873
Declare callbacks extern weak (if no existing declaration exists), and
only call if the function address is non-null.
This allows to attach semantic metadata to binaries where no user of
that metadata exists, avoiding to have to link empty stub callbacks.
Once the binary is linked (statically or dynamically) against a tool
runtime that implements the callbacks, the respective callbacks will be
called. This vastly simplifies gradual deployment of tools using the
metadata, esp. avoiding having to recompile large codebases with
different compiler flags (which negatively impacts compiler caches).
Reviewed By: dvyukov, vitalybuka
Differential Revision: https://reviews.llvm.org/D142408
This reverts commit 45368c75582f0bded1f06d5c82c1f2ee023fb186.
There were some unexpected failures in aarch64 and arm buildbots, I will
have to investigate why these suddenly fell over.
Since bfloat16 and float16 support is not available for i386-freebsd,
the `truncdfbf2.c` and `truncsfbf2.c` builtin sources should be skipped
when targeting that platform, and `COMPILER_RT_HAS_FLOAT16` should not
be defined.
However, the CMake configuration stage runs its tests with the default
target, which normally is amd64-freebsd, so it will detect both bfloat16
and float16 support.
Move adding of the `COMPILER_RT_HAS_FLOAT16` define to the `foreach()`
loop where all the supported architectures are handled, and do not
enable it when targeting i386-freebsd.
Also remove the bfloat16 sources from the `i386_SOURCES` list, when
targeting i386-freebsd.
Differential Revision: https://reviews.llvm.org/D136044
There are no intrinsic functions that leak arguments.
If the called function does not return, the current function
does not return as well, so no possibility of use-after-return.
Sanitizer function also don't leak or don't return.
It's safe to both pass pointers to local variables to them
and to tail-call them.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D142190
