The DWARF debug info should work just as well.
Since 8c03f400a837dc9333e54ab371e7904aa2bec43c in llvm-project,
llvm-symbolizer prefers DWARF over PDB if there is a DWARF section
in the inspected executable. Thus, in order to use PDB, one would
have to strip out any remnants of DWARF debug info from the executable,
like in run-lldb-tests.sh (e.g. by -Wl,-s).
For the purposes of this test, simplifying the setup to use DWARF
works just as well.
When calling make_indirect_call with a parameter which is known,
Clang, since the 18.x release, can end up producing a specialized
version of the function which omits the cfguard check call (as the
target is known) and calls the known target directly.
The function is marked with a noinline attribute, to avoid
the compiler optimizing out the cfguard check call when the
target is known, but even with a noinline function, the compiler
apparently can make a separate specialized version of it.
To avoid the compiler doing such optimizations, reference the
target function via a global variable - the compiler can't assume
anything about the contents of them (they could be altered between
initialization and reading them later).
This fixes the cfguard invalid_icall test with Clang 18.x, when
compiled with optimizations enabled.
It is available on all architectures by default now. Keep the
HAVE_OPENMP conditional within the test makefile to allow custom
testing without having it available.
Since using the ssp routines from mingw-w64 instead of those from
GCC's libssp, these messages are included in the piped output of
the process, so we can check for the right messages.
Use the TOOLEXT variable in run-tests.sh in the same way as in the
Makefile. The Makefile sets this variable automatically if invoked
by mingw32-make, but if running run-tests.sh in WSL with native
Windows compilers, then we need to set TOOLEXT manually when calling
run-tests.sh.
Allow skipping the cfguard failure tests when run in such a
configuration, since Linux make in WSL can't easily run cmd.exe
like in MSYS2.
This part of the tests does pass on glibc on x86_64 and on MSVC,
but fails on macOS (for some functions) and on glibc on aarch64
(for one function).
This is a somewhat overly pedantic test, but is useful for checking
the NAN preservation behaviour when modifying implementations.
Also print the sign bit explicitly - not all printf implementations
distinguish between NAN and -NAN when printed.
When some of the parameters to standard C functions are known
constants, the compiler can optimize out the call to the actual
function.
When built with fortification enabled, the compiler previously
didn't actually end up calling the __<func>_chk functions in
most cases, as it could optimize out much of the calls. Now all
tested function calls should end up emitted as intended, making
this actually do functional testing of the __<func>_chk function
implementations.
The literal NAN in MSVC is a negative NAN, while it is a positive one
in other environments. (strtod("NAN", NULL) did return a positive NAN
though.) In most tests where we test that NANs are preserved, the exact
sign doesn't matter much as long as it matches, but for some tests, it
does matter. Change to using variables with known representation
in the tests where it matters.
Also add a LL suffix to make a tricky constant more correct.
In MSVC, the variable initialization
long long i = -2147483648;
actually sets the variable to the positive value 2147483648 (both
in MSVC 2019 and 2022).
The macros F() and L() etc were meant for providing constants for
the tests, without the compiler seeing them as constants, to
avoid optimizing out the entire functions that are to be tested.
However in practice, the compiler is also able to optimize out
e.g. a call to strtol("42", NULL, 0), so this didn't have the
intended effect.
Instead make the macros wrap through a no-op function, but which
is indirected via a global function pointer. The compiler can't
reason about global variables keeping their values (they could be
modified by e.g. a constructor in a different object file, before
running the main function). This avoids needing to pass all values
through strtod/strtol etc.
Change some constants like 123456789012345, which are seen by
the compiler as integer constants (which aren't exactly representable
in floating point form) into 123456789012345.0, which the compiler
won't complain about being inexact.
If the low byte of the stack cookie happens to be zero, we
previously wouldn't trigger any error.
This avoids accidentally failing to trigger the stack protector
once per 256 runs, roughly.
These are functions that, when built with "-D_FORTIFY_SOURCE=2 -O2",
can end up calling the corresponding __<func>_chk functions - thus,
this can be used for testing those functions.
This allows easier testing of continuing from manually set
breakpoints.
Also fix compilation for non-windows platforms where __debugbreak()
isn't defined.
For x86_64 and aarch64, this requires https://reviews.llvm.org/D89231.
The C++ destructors aren't executed while doing the longjmp (contrary
to how it works MSVC's C++ exceptions), but it no longer crashes.
LLVM's OpenMP implementation only supports Windows on x86, and it
requires a MASM-compatible assembler to build it. Build UASM
for this purpose, for now. (UASM isn't available packaged in
debian/ubuntu repos.) In the future, llvm-ml should be able
to handle it instead, but it's not currently mature enough.
Not including it in the regular build-all.sh for now, as UASM
isn't generally available.
Martin Storsjö