Don't declare some types that FreeBSD incorrectly declares.
Fix an incorrect call to open() (missing mode).
ANSIfy prototypes.
Enable SysV message queue, semaphore, and shared memory tests.
With exception of the workaround for union semun, these fixes have been
committed to NetBSD.
Reviewed by: asomers
Approved by: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D13471
Some of the ptrace tests need to wait for a child process to become a
zombie before preceding. The parent process polls the child process
via the kern.proc.pid sysctl to wait for it to become a zombie.
Previously the code polled until the sysctl failed with ESRCH. Now it
will poll until either the sysctl fails with ESRCH (for compatiblity
with older kernels) or returns a kinfo_proc structure with the ki_stat
field set to SZOMB.
Reported by: Jenkins
Tested by: markj
Discussed with: mjg
MFC after: 1 week
When multiple threads wish to report a tracing event to a debugger,
both threads call ptracestop() and one thread will win the race to be
the reporting thread (p->p_xthread). The debugger uses PT_LWPINFO
with the process ID to determine which thread / LWP is reporting an
event and the details of that event. This event is cleared as a side
effect of the subsequent ptrace event that resumed the process
(PT_CONTINUE, PT_STEP, etc.). However, ptrace() was clearing the
event identified by the LWP ID passed to the resume request even if
that wasn't the 'p_xthread'. This could result in clearing an event
that had not yet been observed by the debugger and leaving the
existing event for 'p_thread' pending so that it was reported a second
time.
Specifically, if the debugger stopped due to a software breakpoint in
one thread, but then switched to another thread that was used to
resume (e.g. if the user switched to a different thread and issued a
step), the resume request (PT_STEP) cleared a pending event (if any)
for the thread being stepped. However, the process immediately
stopped and the first thread reported it's breakpoint event a second
time. The debugger decremented the PC for "both" breakpoint events
which resulted in the PC now pointing into the middle of an
instruction (on x86) and a SIGILL fault when the process was resumed a
second time.
To fix, always clear the pending event for 'p_xthread' when resuming a
process. ptrace() still honors the requested LWP ID when enabling
single-stepping (PT_STEP) or setting a different PC (PT_CONTINUE).
Reported by: GDB testsuite (gdb.threads/continue-pending-status.exp)
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D12794
Executable bits should be set at install time instead of in the repo.
Setting executable bits on files triggers false positives with Phabricator.
MFC after: 2 months
- Use "atf_check -x 'cmd1 | cmd2'" instead of "cmd1 | atf_check cmd2". The
two forms are idiomatically similar, but subtly different in the sense of
what program invokes the other, and there could be unwanted side effects
of the latter idiom dealing with forking, pipes, etc.
- Remove chmod and instead source coredump_phnum_restore_state.sh directly.
This avoids the need to check the result of the chmod call.
- Fix indentation in an if-block (4 column space indentation -> hard tab).
The testcase no longer fails on ^/head because readelf has established parity
with binutils' copy of readelf.
This issue is not seen on Jenkins because
`test_suites.FreeBSD.allow_sysctl_side_effects` isn't set in kyua.conf on
the CI host, i.e., the test is skipped.
PR: 215019
Tested with: binutils (amd64-binutils-2.28,1); elftoolchain (r3561M)
It was sending only a long's worth (4 or 8 bytes) of data previously
(instead of the entire buffer) via send(2).
MFC after: 1 week
Reported by: Coverity
CID: 1229966, 1229967, 1230004, 1230005
Sponsored by: Dell EMC Isilon
These command take an int. The tests work by accident on little-endian,
64-bit systems.
PR: 218919
Tested with: qemu-cheri and CheriBSD built for mips64
Reviewed by: asomers, ngie
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D10518
available and if that is true make use of them.
Thank you very much to Andrew Turner for providing help and review the patch!
Reviewed by: andrew
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10499
A couple of the ptrace tests make assumptions about which thread in a
multithreaded process will run after a halt. This makes the tests less
portable across branches, and susceptible to future breakage. Instead,
twiddle thread scheduling and priorities to match the tests'
expectation.
X-MFC with: r313992
Sponsored by: Dell EMC
The ptrace() user has the option of discarding the signal. In such a
case, p_ptevents should not be modified. If the ptrace() user decides to
send a SIGKILL, ptevents will be cleared in ptracestop(). procfs events
do not have the capability to discard the signal, so continue to clear
the mask in that case.
Reviewed by: jhb (initial revision)
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D9939
Suppose a traced process is stopped in ptracestop() due to receipt of a
SIGSTOP signal, and is awaiting orders from the tracing process on how
to handle the signal. Before sending any such orders, the tracing
process exits. This should kill the traced process. But suppose a second
thread handles the SIGKILL and proceeds to exit1(), calling
thread_single(). The first thread will now awaken and will have a chance
to check once more if it should go to sleep due to the SIGSTOP. It must
not sleep after P_SINGLE_EXIT has been set; this would prevent the
SIGKILL from taking effect, leaving a stopped orphan behind after the
tracing process dies.
Also add new tests for this condition.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D9890
When a thread is stopped in ptracestop(), the ptrace(2) user may request
a signal be delivered upon resumption of the thread. Heretofore, those signals
were discarded unless ptracestop()'s caller was issignal(). Fix this by
modifying ptracestop() to queue up signals requested by the ptrace user that
will be delivered when possible. Take special care when the signal is SIGKILL
(usually generated from a PT_KILL request); no new stop events should be
triggered after a PT_KILL.
Add a number of tests for the new functionality. Several tests were authored
by jhb.
PR: 212607
Reviewed by: kib
Approved by: kib (mentor)
MFC after: 2 weeks
Sponsored by: Dell EMC
In collaboration with: jhb
Differential Revision: https://reviews.freebsd.org/D9260
Derived from an implementation by Mark Adler.
The fast loop performs three simultaneous CRCs over subsets of the data
before composing them. This takes advantage of certain properties of
the CRC32 implementation in Intel hardware. (The CRC instruction takes 1
cycle but has 2-3 cycles of latency.)
The CRC32 instruction does not manipulate FPU state.
i386 does not have the crc32q instruction, so avoid it there. Otherwise
the implementation is identical to amd64.
Add basic userland tests to verify correctness on a variety of inputs.
PR: 216467
Reported by: Ben RUBSON <ben.rubson at gmail.com>
Reviewed by: kib@, markj@ (earlier version)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D9342
between exp(3) and `exp` var.
The approach taken previously was not ideal for multiple
functional and stylistic reasons.
Add to existing sed call in Makefile to replace `exp` with
`exponent` instead.
MFC after: 13 days
Requested by: bde
The primary goal for doing this is to leverage the work done in r312114
for enabling WARNS to address trivial code quality issues with new tests
MFC after: 6 days
Tested with: make tinderbox
Sponsored by: Dell EMC Isilon
State that execve failed instead of just printing out the program name
and strerror(errno) via err(3).
MFC after: 3 days
X-MFC with: r312118
Sponsored by: Dell EMC Isilon
Note: this test still requires binutils readelf (from ports) to pass, until a
few issues are resolved in elftoolchain.
PR: 215019
Reported by: ngie@
Sponsored by: Dell EMC Isilon
The requirement is set via `atf_set "require.config" "allow_sysctl_side_effects"',
not `atf_set "require.config" "allow_sysctl_side_effects"'
X-MFC with: r308177
Pointyhat to: cmeyer
If wait4() or wait6() return 0 because of WNOHANG, the status, rusage and
wrusage information should not be returned.
PR: 212048
Reported by: Casey Lucas
MFC after: 2 weeks
First, PL_FLAG_FORKED events now also set a PL_FLAG_VFORKED flag when
the new child was created via vfork() rather than fork(). Second, a
new PL_FLAG_VFORK_DONE event can now be enabled via the PTRACE_VFORK
event mask. This new stop is reported after the vfork parent resumes
due to the child calling exit or exec. Debuggers can use this stop to
reinsert breakpoints in the vfork parent process before it resumes.
Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D7045
ptrace() now stores a mask of optional events in p_ptevents. Currently
this mask is a single integer, but it can be expanded into an array of
integers in the future.
Two new ptrace requests can be used to manipulate the event mask:
PT_GET_EVENT_MASK fetches the current event mask and PT_SET_EVENT_MASK
sets the current event mask.
The current set of events include:
- PTRACE_EXEC: trace calls to execve().
- PTRACE_SCE: trace system call entries.
- PTRACE_SCX: trace syscam call exits.
- PTRACE_FORK: trace forks and auto-attach to new child processes.
- PTRACE_LWP: trace LWP events.
The S_PT_SCX and S_PT_SCE events in the procfs p_stops flags have
been replaced by PTRACE_SCE and PTRACE_SCX. PTRACE_FORK replaces
P_FOLLOW_FORK and PTRACE_LWP replaces P2_LWP_EVENTS.
The PT_FOLLOW_FORK and PT_LWP_EVENTS ptrace requests remain for
compatibility but now simply toggle corresponding flags in the
event mask.
While here, document that PT_SYSCALL, PT_TO_SCE, and PT_TO_SCX both
modify the event mask and continue the traced process.
Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D7044
tests/sys/kern/Makefile
Reenable a disabled compiler warning, the need for which was
eliminated by r299090.
Reviewed by: ngie
MFC after: 4 weeks
X-MFC-With: 299090
Sponsored by: Spectra Logic Corp
after r298107
Summary of changes:
- Replace all instances of FILES/TESTS with ${PACKAGE}FILES. This ensures that
namespacing is kept with FILES appropriately, and that this shouldn't need
to be repeated if the namespace changes -- only the definition of PACKAGE
needs to be changed
- Allow PACKAGE to be overridden by callers instead of forcing it to always be
`tests`. In the event we get to the point where things can be split up
enough in the base system, it would make more sense to group the tests
with the blocks they're a part of, e.g. byacc with byacc-tests, etc
- Remove PACKAGE definitions where possible, i.e. where FILES wasn't used
previously.
- Remove unnecessary TESTSPACKAGE definitions; this has been elided into
bsd.tests.mk
- Remove unnecessary BINDIRs used previously with ${PACKAGE}FILES;
${PACKAGE}FILESDIR is now automatically defined in bsd.test.mk.
- Fix installation of files under data/ subdirectories in lib/libc/tests/hash
and lib/libc/tests/net/getaddrinfo
- Remove unnecessary .include <bsd.own.mk>s (some opportunistic cleanup)
Document the proposed changes in share/examples/tests/tests/... via examples
so it's clear that ${PACKAGES}FILES is the suggested way forward in terms of
replacing FILES. share/mk/bsd.README didn't seem like the appropriate method
of communicating that info.
MFC after: never probably
X-MFC with: r298107
PR: 209114
Relnotes: yes
Tested with: buildworld, installworld, checkworld; buildworld, packageworld
Sponsored by: EMC / Isilon Storage Division
