0904a3bc79
dbregs2: Verify that setting DR0 is preserved across ptrace(2) calls dbregs3: Verify that setting DR1 is preserved across ptrace(2) calls dbregs4: Verify that setting DR2 is preserved across ptrace(2) calls dbregs5: Verify that setting DR3 is preserved across ptrace(2) calls These tests are deliberately fine-grained as they are expected to penetrate precisely each functional aspect of CPU Debug Registers on amd64 one after another. These tests (and MI ones) might be generated or merged with helper functions, however in order to copy-and-paste them out of a test-suite and quickly port to other platform (in order to compare results) it's useful to keep them as stand-alone as they are. Code from these tests might be shared with other ports in future, for the same reason keep them currently as they are. Sponsored by <The NetBSD Foundation> |
||
---|---|---|
.. | ||
bin | ||
crypto | ||
dev | ||
fs | ||
games | ||
include | ||
ipf | ||
kernel | ||
lib | ||
libexec | ||
modules | ||
net | ||
rump | ||
sbin | ||
share | ||
sys | ||
usr.bin | ||
usr.sbin | ||
h_macros.h | ||
Makefile | ||
Makefile.inc | ||
README |
$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $ When adding new tests, please try to follow the following conventions. 1. For library routines, including system calls, the directory structure of the tests should follow the directory structure of the real source tree. For instance, interfaces available via the C library should follow: src/lib/libc/gen -> src/tests/lib/libc/gen src/lib/libc/sys -> src/tests/lib/libc/sys ... 2. Equivalently, all tests for userland utilities should try to follow their location in the source tree. If this can not be satisfied, the tests for a utility should be located under the directory to which the utility is installed. Thus, a test for env(1) should go to src/tests/usr.bin/env. Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump, even though the source code for the program is located under src/external. 3. Otherwise use your own discretion.