Add new cc and c++ tests to check whether UBSan works.
These tests are prepared for GCC (in base) and Clang (with external patches).
Enable these tests for all ports by default, just verify whether we are
using GCC/Clang or a compatible compiler.
Add five equivalent C and C++ tests:
- Integer addition overflow
- Integer divide by zero
- Integer negation overflow
- Integer subtraction overflow
- VLA out of bounds
All tests pass on NetBSD/amd64.
Patch submitted by <Harry Pantazis>
Minor cleanup by <myself>
Add new tests:
- tests/usr.bin/cc/t_asan_poison.sh
- tests/usr.bin/c++/t_asan_poison.sh
These tests verify the following build options:
- regular
- profile
- pic
- pie
- compat32
- (static unsupported)
These tests verify whether ASan code can include compiler and sanitizer
specific header: <sanitizer/asan_interface.h>. The testing code checks
the ASAN_POISON_MEMORY_REGION() functionality, poisoning valid memory and
asserting that it triggers expected failure.
Patch submitted by <Siddharth Muralee>
Add new C and C++ tests:
- t_asan_double_free
- t_asan_global_buffer_overflow
- t_asan_heap_overflow
- t_asan_off_by_one
- t_asan_uaf
Each tests checks:
- regular build
- 32-bit
- PIC
- PIE
- profile
These tests require paxctl(8) to disable ASLR in order to work in a
predictable way. This is especially true for all !regular builds with
additional compiler flags.
There are no static variations of these tests as this mode is not supported
in upstream ASan.
Enable these tests on amd64 and i386.
This is part two patch, adding the remaining C++ changes.
Patch submitted by <Siddharth Muralee>
Additional polishing by myself.
Add new C and C++ tests:
- t_asan_double_free
- t_asan_global_buffer_overflow
- t_asan_heap_overflow
- t_asan_off_by_one
- t_asan_uaf
Each tests checks:
- regular build
- 32-bit
- PIC
- PIE
- profile
These tests require paxctl(8) to disable ASLR in order to work in a
predictable way. This is especially true for all !regular builds with
additional compiler flags.
There are no static variations of these tests as this mode is not supported
in upstream ASan.
Enable these tests on amd64 and i386.
Patch submitted by <Siddharth Muralee>
Additional polishing by myself.
adequate, but for a device, we really need to actually try opening
it to determine that it is possible - so do the test that way, then
if the open succeeds once, assume it will the second time (which then
holds it open.)
causes the shell to exit if the redirect fails (posix says "may exit"
and /bin/sh does - maybe should give that more thought) - which will
happen if /dev/pad0 does not exist, causing a very messy test abort
(the shell running the test is not supposed to just go away). So
check tha the device exista and is readable before attempting to open it.
Problem brought to my attention by nat@ - thanks...
least been attempted) before attempting to open /dev/mixer to determine
if the system being tested has audio or not. Leaving this for the background
cat command to do causes a race between that command and the parent sh.
Move this code to a helper function to avoid duplicating it.
Also avoid attempting to kill the background cat if it was never created.
The kill is likely unnecessary anyway, ATF seems to clean up processes
like that one without assistance. Which is a good thing, as the kill
does not happen if the test is skipped, or fails.
These tests are cloned from t_cxxruntime and check proper order of destructor
calls. They must be reported in reverse order of constructor completion.
Added tests:
- static_destructor
- static_destructor_pic
- static_destructor_pie
- static_destructor32
This test file replaces src/regress/usr.bin/c++/static_destructor.
This is a copy of t_hello from usr.bin/cc.
Added tests:
- hello
- hello_pic
- hello_pie
- hello32
These tests do not use c++ runtime library functions.
Protect these tests with MKCXX.
the corresponding pad device open, or we get EIO from audio accesses
Explained and fix provided by Nathanial Sloss <nat@n.o>
Note: if we are testing and using real audio hardware, the open
of /dev/pad0 is irrelevant (but harmless, so we don't attempt to
check) and what's more it doesn't matter if it succeeds or fails.
If we're testing under qemu (or any other situation where the only
audio "hardware" is pad) then the open will work, and there should be
no more EIO.
If there is no audio hardware of any kind on the system being tested,
the attempt top open /dev/mixer should fail, and the test will be
skipped.
can't be opened (which more accurately reflects when mixerctl is going
to fail...)
Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)
While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.
as the kernel that runs them has no audio (and no mixers) configured.
The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).
Add a test program for the bug described in this PR.
This is the first pkill/pgrep/prenice test (more would be good!)
This test has been confirmed to work once the bug described in the PR
has been fixed, so the test is not marked "expected to fail" even
though initially that is what should happen.
Note: the test cana also fail if the system running the tests happens
to be running processes with names that match the patterns searched for
by the test, other than the test program itself. This is expected to be
unlikely.
size of the previous one (using on-the-fly gzip compression), and includes
more cases (including a gpg-signed file for cross-testing purposes).
Add the appropriate Testspec file.
