[DTrace-devel] [oracle/dtrace-utils] 8e1bdb: uprobes: name uprobes based on offset in inode rat...
Kris Van Hees
noreply at github.com
Wed Nov 8 21:09:24 UTC 2023
Branch: refs/heads/kvh/2.0-branch-dev
Home: https://github.com/oracle/dtrace-utils
Commit: 8e1bdb8d163f2679685a9df5bf73c9fa27573571
https://github.com/oracle/dtrace-utils/commit/8e1bdb8d163f2679685a9df5bf73c9fa27573571
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-07 (Tue, 07 Nov 2023)
Changed paths:
M libcommon/uprobes.c
Log Message:
-----------
uprobes: name uprobes based on offset in inode rather than address
When PIC code is used, USDT probes (using uprobes) can appear at different
addresses for distinct instances of the same ELF object because the base
address is not fixed. As a result, uprobes were being created using names
that were not stable. Since (dev, inode, offset) is a unique triplet for
any uprobe, use that instead of (dev, inode, address).
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 2096fd774aa7459bb106337dc600acc25b31f3d6
https://github.com/oracle/dtrace-utils/commit/2096fd774aa7459bb106337dc600acc25b31f3d6
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-07 (Tue, 07 Nov 2023)
Changed paths:
M libdtrace/dt_link.c
A test/unittest/usdt/tst.pie.r
A test/unittest/usdt/tst.pie.sh
Log Message:
-----------
usdt: remove relocations rather than changing their type to R_*_NONE
The original DTrace code used to depend on STV_ELIMINATE and XXX
to have the linker clean up USDT probe related relocations. This
does not work on Linux, so DTrace on Linux changed the type of those
relocations to be R_*_NONE since those relocations get ignored.
Binutils no longer allows that for PIC objects when a locally referenced
symbol is involved.
DTrace will now remove those relocations since they are no longer needed
anyway.
A test is included to ensure that PIC objects can be linked successfully
when USDT probes are used.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 2a10fabc652676825fa95ff07fbc4ffe5944485e
https://github.com/oracle/dtrace-utils/commit/2a10fabc652676825fa95ff07fbc4ffe5944485e
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M GNUmakefile
M libdtrace/Build
Log Message:
-----------
build: support kernel builds with or without object directory
It should be possible to build DTrace against kernel headers provided in
a variety of ways. They can be provided as installed kernel header
packages with combined or separated generated and standard headers, and
linked from /lib/modules/<kernelv-version> or simply available as
directory hierarchies elsewhere on the system.
It should also be possible to build DTrace against kernel headers that
are found in a locally built kernel, whether it is installed or not.
This patch provides a cleanup for the build system to accomplish this
with minimal configuration.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 402377cde40ef9f227d5755a3ceb850c70292d9d
https://github.com/oracle/dtrace-utils/commit/402377cde40ef9f227d5755a3ceb850c70292d9d
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/Build
A libdtrace/dt_btf.c
A libdtrace/dt_btf.h
M libdtrace/dt_impl.h
M libdtrace/dt_module.c
Log Message:
-----------
ctf: add BTF-to-CTF convertor
For kernels that do not provide CTF data, kernel type information can be
obtained at runtime as BTF data. We pull in that data and generate
equivalent CTF data from it.
Note that BTF is not a true replacement for CTF data. I.e. it does not
currently provide type information for kernel variables.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: defa6827ce88b8655c8a7a36cf24d8e6badb1b69
https://github.com/oracle/dtrace-utils/commit/defa6827ce88b8655c8a7a36cf24d8e6badb1b69
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/io.d.in
Log Message:
-----------
dlibs: add typedef for caddr_t to io.d.in
The bufinfo struct (standard in DTrace) contains members of type caddr_t.
It is not a standard datatype, so we add an explicit typedef for it.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: a2343d667d2f3c0c913489fb3ac513e286b50ba1
https://github.com/oracle/dtrace-utils/commit/a2343d667d2f3c0c913489fb3ac513e286b50ba1
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/dt_module.c
Log Message:
-----------
module: use uintptr_t as type for kernel symbols withuot type info
When a kernel symbol is known to exist (found in kallsyms) but no type
information can be found, a compilation error is reported. That makes
it impossible to use casting to resolve missing type information for
symbols whose address is clearly known. So, assign those symbol the
uintptr_t type.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 97b4e614581ec80940a46d56b6f3c74db08f4c98
https://github.com/oracle/dtrace-utils/commit/97b4e614581ec80940a46d56b6f3c74db08f4c98
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/io.d.in
M test/unittest/assocs/err.D_OP_INCOMPAT.dupgtype.d
M test/unittest/assocs/err.D_OP_INCOMPAT.dupgtype.r
A test/unittest/assocs/err.D_OP_INCOMPAT.dupgtype.r.p
M test/unittest/assocs/err.D_OP_INCOMPAT.dupttype.d
M test/unittest/assocs/err.D_OP_INCOMPAT.dupttype.r
A test/unittest/assocs/err.D_OP_INCOMPAT.dupttype.r.p
M test/unittest/codegen/tst.kernel_read_deref_indirect_str.d
M test/unittest/codegen/tst.kernel_read_deref_struct.d
M test/unittest/codegen/tst.kernel_read_index_indirect_str.d
M test/unittest/codegen/tst.kernel_read_indirect_scalar.d
M test/unittest/codegen/tst.kernel_read_str.d
M test/unittest/funcs/strjoin/tst.strjoin_nonDPTR.d
M test/unittest/funcs/strtok/tst.strtok_nonDPTR.d
M test/unittest/funcs/substr/tst.substr_nonDPTR.d
M test/unittest/funcs/tst.basename_nonDPTR.d
M test/unittest/funcs/tst.dirname_nonDPTR.d
M test/unittest/funcs/tst.index_nonDPTR.d
M test/unittest/funcs/tst.rindex_nonDPTR.d
M test/unittest/funcs/tst.strchr_nonDPTR.d
M test/unittest/funcs/tst.subr.d
M test/unittest/inline/tst.InlineDataAssign.d
M test/unittest/inline/tst.InlineExpression.d
M test/unittest/inline/tst.InlineTypedef.d
M test/unittest/lexer/tst.keyword-member.d
R test/unittest/options/err.ctfpath.d
M test/unittest/options/err.ctfpath.r
A test/unittest/options/err.ctfpath.sh
A test/unittest/options/tst.ctfpath.x
A test/unittest/options/tst.modpath.x
M test/unittest/pointers/tst.GlobalVar.d
M test/unittest/pointers/tst.basic1.d
M test/unittest/pointers/tst.basic2.d
M test/unittest/scalars/err.D_OP_INCOMPAT.dupgtype.d
M test/unittest/scalars/err.D_OP_INCOMPAT.dupltype.d
M test/unittest/scalars/err.D_OP_INCOMPAT.dupttype.d
M test/unittest/struct/tst.StructDataTypes.d
M test/unittest/trace/tst.misc.d
M test/unittest/tracemem/err.D_TRACEMEM_ADDR.badaddr.d
M test/unittest/tracemem/err.D_TRACEMEM_ADDR.badaddr.r
M test/unittest/union/tst.UnionDataTypes.d
Log Message:
-----------
dlibs, test: reduce complexity of tests
Some tests depended on kernel variable type information that is not
currently available when only BTF type data can be found. Use
explicit casting:
Some tests used kernel variables without needing to. Use other
sources that provide the same functionality:
Some tests should be skipped when there is no CTF archive:
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: 6f52ca742b6cea6d9dedd467d494949e2c126f72
https://github.com/oracle/dtrace-utils/commit/6f52ca742b6cea6d9dedd467d494949e2c126f72
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/dt_module.c
Log Message:
-----------
module: support kallsyms with modules.builtin.ranges
Extend the support for different forms of symbol-to-address information
with nodule association. We now support three different variaties:
- kallmodsyms
- kallsyms with modules.builtin.ranges
- kallsyms w/o modules.builtin.ranges
The modules.builtin.ranges file contains data about address ranges that
contain symbols for one or more built-in modules. Since the load
address of each kernel section is not known at kernel buildtime, this
file stores offset ranges relative to the load address of the section.
The file will look like this:
.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 008e6660-008e9630 snd_soc_wcd_mbhc
.text 008e9630-008ea610 snd_soc_wcd9335 snd_soc_wcd934x snd_soc_wcd938x
.text 008ea610-008ea780 snd_soc_wcd9335
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore
For each ELF section, it lists the offset of the first symbol. This can
be used to deteermine the base address of the section at runtime.
Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules. Multiple ranges
can apply to a single module, and ranges can be shared between modules.
When processing /proc/kallsyms with modules.builtin.ranges data, symbols
are annotated (as applicable) with a built-in module name. If a symbol
belongs to multiple modules, multiple copies of the symbol will be added
with the same address but distinct module names. This means that the
symbol will be found with modname`symname lookups, but reverse lookup on
the address will always give the first one found. This is consistent
with existing behaviour in DTrace when two symbols refer to the same
address.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Nick Alcock <nick.alcock at oracle.com>
Commit: e153420f29079c470f94dcb52fdf5da6141cc352
https://github.com/oracle/dtrace-utils/commit/e153420f29079c470f94dcb52fdf5da6141cc352
Author: Nick Alcock <nick.alcock at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/dt_consume.c
M libdtrace/dt_proc.c
M libdtrace/dt_proc.h
Log Message:
-----------
Revert "Exit properly when all dtrace -c processes end, even if waitfd() failed."
This reverts commit e856890a68c5b2461f30499295f4f8583b8efed4.
We will no longer need it when waitfd is gone.
This also removes a whole pile of complexity where we might sometimes have
to synchronously check to see if the process has exited, simply because
we couldn't rely on waitfd() working everywhere.
Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: c883bd437cfbb8269ebbe6c78171a0d2e08c029c
https://github.com/oracle/dtrace-utils/commit/c883bd437cfbb8269ebbe6c78171a0d2e08c029c
Author: Nick Alcock <nick.alcock at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M Makeconfig
M README.md
M include/arm64/platform.h
M include/i386/platform.h
M include/port.h
M include/sys/compiler.h
M libdtrace/dt_impl.h
M libdtrace/dt_open.c
M libdtrace/dt_proc.c
M libdtrace/dt_proc.h
M libdtrace/dtrace.h
M libdtrace/libdtrace.ver
M libport/Build
R libport/arm64/waitfd.c
R libport/i386/waitfd.c
R libport/sparc/waitfd.c
M libproc/Pcontrol.c
M libproc/Pcontrol.h
M libproc/libproc.h
M libproc/rtld_db.c
M libproc/wrap.c
M test/triggers/libproc-consistency.c
M test/triggers/libproc-execing-bkpts.c
M test/triggers/libproc-lookup-by-name.c
Log Message:
-----------
proc: rip out waitfd() and hit waitpidding thread with a signal instead
For a long time we have used waitfd() to allow our process-monitoring
threads to wait for messages from DTrace proper (via a pipe) and state
changes from the monitored process (via Pwait(), which calls waitpid())
without having to engage in CPU-chewing polling loops and without inducing
latency in the monitored process or in responses to DTrace. (Both matter:
the proxying mechanism is quite fine-grained. The main DTrace thread can
mess around in libproc as much as it likes, with individual Ptrace() calls
being automatically proxied to the monitoring thread down the pipe. So
single operations from the perspective of DTrace's main thread can involve
dozens of proxy calls. Excessive latency would be bad.)
But waitfd() is ugly enough that it's never going to go upstream: not only
was it already rejected in 2010, but it needs to add really ugly hacks to
the waitqueue mechanism and even disable some assetions because it bloats
some core polling data structures beyond a cacheline (theoretically slowing
them down, though I've never been able to measure anything).
So it would be very nice to get rid of it.
The solution is an old Unix horror: EINTR. Everyone hates it, everyone wraps
long-running syscalls in EINTR loops to evade it... and here it does just
what we want. We find an unused realtime signal (the only WIP: actually hunt
one down rather than just stamping on one) and unmask it in the monitoring
thread, then drop the whole waitfd thing entirely and typically wait in
waitpid() (only waiting blocked on poll() on the proxy pipe if we're
explicitly not listening to the process right now). When we send a proxy
message to a monitoring thread, we hit it with this signal, which causes
waitpid() to exit with EINTR -- and once it does that we can check the proxy
pipe and process any messages, with no polling loops or added latencies.
We use SIGRTMIN as the signal by default: if the caller is one of those few
that actually uses realtime signals for something, we provide a new
dtrace_set_internal_signal API function that the caller can invoke before
calling dtrace_open to reset the signal to some other value that the caller
is not using (specified as a number to be added to SIGRTMIN, since we *do*
require that it's a realtime signal).
This requires an additional hook, analogous to the existing ptrace_lock_hook
(which is used to take out the dpr_lock around Ptrace() calls, so that no
other Ptrace() calls can happen for that process at the same time). This
one, the waitpid_lock_look, is used to *drop* the lock around the call to
waitpid(), because the waitpid() call may now take a long time, and the
proxy calling mechanism has to take out the dpr_lock (because it protects
the dpr_msg_cv condvar that mediates the proxy call). But we can't drop the
dpr_lock around the call to Pwait() as a whole because that call also
invokes all the breakpoint handlers, and *that* work requires the dpr_lock
to have been already taken out by Pwait()s caller. So we need another
hook. Thankfully the two hooks are never nested!
This does have one race we haven't fixed yet, because the fix is quite
involved: see the next commit.
Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 234b39beb0e0083381df6bb498491f2904d5d087
https://github.com/oracle/dtrace-utils/commit/234b39beb0e0083381df6bb498491f2904d5d087
Author: Nick Alcock <nick.alcock at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M Makeconfig
M include/port.h
M libdtrace/dt_proc.c
M libdtrace/dt_proc.h
M libport/Build
A libport/gettid.c
M test/unittest/pid/tst.manypids.sh
Log Message:
-----------
proc: fix race between dt_proc_signal receipt and waitpid()
There is one tricky race in the hit-waitpid-with-a-signal approach used
in the last commit: sending messages to the monitor thread can race with
waitpid() itself.
We check to see if a proxy message has arrived immediately before
starting waitpid() (which requires some annoying prototype changes to
Pwait() to pass the relevant variable down), but there is a race here:
if (return_early && *return_early > 0) {
if (block && waitpid_lock_hook)
waitpid_lock_hook(P, P->wrap_arg, 0);
return 0;
}
-->
err = waitpid(P->pid, &status, __WALL | (!block ? WNOHANG : 0));
At the indicated point, if a proxy signal hits, waitpid() will not
return EINTR because it hasn't started yet, but the return_early
variable changing its state (via the signal handler) will not be spotted
either because it's arrived too late. The elegant way to fix this would
be something like ppoll() or pselect() but for waitpid(): a waitpid()
variant which atomically applies a signal mask as it starts up.
But we don't have that, and we're not likely to any time soon. Is there
some alternative approach? This race is, unfortunately, quite easy to
hit at dtrace -c startup: connection and breakpoint setup involves a
whole bunch of Pwait() calls, and at the same time the monitor thread is
likely to be doing a whole bunch of proxy calls too, so they're likely
to intersect badly quite fast.
Reviving test/unittest/pid/tst.manypids.sh -- whose purpose appears to
be to LD_PRELOAD a more or less random pile of libraries, some of who
might have constructors that malloc(), then run a lot of sleep(1)s under
those preloads and watch them for mallocs -- so that it preloads
libraries that actually exist on Linux easily triggers this problem.
The key is that the race is only brief. We can exploit this by setting
up a timer that repeatedly hits the monitor thread with the proxy-call
signal; if the first one is missed it will soon be followed by many
more, one of which will soon hit when the waitpid() is running and
-EINTR it properly: keep sending signals and as long as the monitor
thread is working at all it will soon get woken up.
The only tricky part is that doing a pthread_kill() from a timer (rather
than just a kill()) requires a non-portable "intended only for use by
threading libraries" SIGEV_THREAD_ID flag to timer_create(), in
conjunction with a use of a nonportable field in the struct sigevent:
but the latter field is part of the ABI and cannot change, and the
SIGEV_THREAD_ID option is used by glibc's implementation of SIGEV_THREAD
and thus can be assumed to have stable semantics as well. So we can use
it without fear. (The only tricky part is getting the Linux-facing
thread ID, for which we need gettid() even if glibc is too old to
provide it.)
To avoid excessive expense doing all this madness on every proxy call,
we set up the actual timer in advance, as the monitor thread starts, and
only arm it when the proxy_call() happens. We disarm it twice: in
proxy_call() in case the signal hit when the monitor thread wasn't in
waitpid() at all, and in the waitpid_lock_hook so that if it *is* in
waitpid(), it is disarmed immediately after waitpid() returns and
doesn't keep hitting us with pointless signals after they are no longer
needed.
We set the interval to 1ms as a reasonable latency on proxy calls when
we are unlucky enough to hit this race window, and an initial value of
1ms so that we don't take the cost of firing the timer at all in the
vast majority of cases. (Any additional CPU load incurred by this
change is in the noise even summed over hundreds of runs. It adds three
syscalls per proxy call, which given the sheer overhead of doing
anything at all with ptrace() and the fact that doing a proxy call
already involves cross-thread condvar operations and lock manipulation
is not going to be noticeable.)
The timer should only ever fire briefly, but if anything goes
badly-enough wrong the timer might keep firing for some time. If the
timer *does* fire repeatedly, no harm is done: each firing has no effect
other than to set waitpid_interrupted and force some syscall to return
-EINTR. Hopefully we've surrounded all blocking syscalls this might
interrupt with an EINTR loop... and if not, that's a bug that needs
fixing regardless.
(An audit of relevant bits of dt_proc and libproc is underway. I expect
a few changes, but not very many.)
Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 1993678e807a822992d763a369e2b36b4d69ded4
https://github.com/oracle/dtrace-utils/commit/1993678e807a822992d763a369e2b36b4d69ded4
Author: Nick Alcock <nick.alcock at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
R include/mutex.h
M include/port.h
M libdtrace/dt_pid.c
M libdtrace/dt_proc.c
M libport/time.c
M libproc/Pcontrol.c
M libproc/Psymtab.c
Log Message:
-----------
port: delete useless mutex.h and mutex_* wrappers
Only MUTEX_HELD() is used more than once and even that is only used with
locks that are otherwise used only with the POSIX pthreads API.
Simplify things, drop mutex.h and all its uses, and move to using pthreads
locks everywhere (rather than only almost everywhere). Move MUTEX_HELD into
port.h where it belongs.
Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 6b1618e420d58ae03e58eaeaa8b07627eca599b4
https://github.com/oracle/dtrace-utils/commit/6b1618e420d58ae03e58eaeaa8b07627eca599b4
Author: Nick Alcock <nick.alcock at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libcommon/dof_parser_host.c
M libdtrace/dt_pcap.c
M libdtrace/dt_proc.c
M libproc/Pcontrol.c
M libproc/elfish.c
Log Message:
-----------
EINTR: make safe under signal hits
This commit audits DTrace (especially libproc and dt_proc) for syscalls and
library calls that may return EINTR but are not suitably guarded, and guards
them, adjusting any that use timeouts so that the timeout ignores the
interruption. (The plan was also to have any of them that needed to
actually *use* this EINTR to trigger an early return to do that as well, but
it turns out that none do, not even the ones in libproc.)
This matters for libproc and dt_proc in particular now because the monitor
thread is routinely hit by signals and so has to expect EINTR returns from
appropriate syscalls (and consider what to do if that happens, because it
means a proxy request is waiting and the DTrace main thread is blocked on
it).
This does not touch the core polling loop in dt_consume, since that loop is
*expected* to return -EINTR, triggering an -EINTR return from dtrace_go()
(see cmd/dtrace.c's call to that function). This may be a bug, since it
means that repeatedly changing the window size is enough to cause DTrace to
ignore the switchrate -- but the caller might well *want* an -EINTR return
so it can handle whatever signal just hit.
Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
Commit: 347ad8afa3a13135641ea2e6c73692d1743254be
https://github.com/oracle/dtrace-utils/commit/347ad8afa3a13135641ea2e6c73692d1743254be
Author: Kris Van Hees <kris.van.hees at oracle.com>
Date: 2023-11-08 (Wed, 08 Nov 2023)
Changed paths:
M libdtrace/dt_cg.c
M libdtrace/dt_consume.c
M libdtrace/dt_open.c
M libdtrace/dt_pcap.h
M libdtrace/pcap.d
A test/unittest/pcap/err.D_PROTO_ARG.pcap_non_scalar_arg1.d
A test/unittest/pcap/err.D_PROTO_ARG.pcap_non_scalar_arg1.r
A test/unittest/pcap/err.D_PROTO_ARG.pcap_non_scalar_arg2.d
A test/unittest/pcap/err.D_PROTO_ARG.pcap_non_scalar_arg2.r
A test/unittest/pcap/err.D_PROTO_LEN.pcap_missing_arg.d
A test/unittest/pcap/err.D_PROTO_LEN.pcap_missing_arg.r
A test/unittest/pcap/err.D_PROTO_LEN.pcap_too_few_args.d
A test/unittest/pcap/err.D_PROTO_LEN.pcap_too_few_args.r
A test/unittest/pcap/err.D_PROTO_LEN.pcap_too_many_args.d
A test/unittest/pcap/err.D_PROTO_LEN.pcap_too_many_args.r
M test/unittest/pcap/tst.pcap.file.sh
A test/unittest/pcap/tst.pcap.regleak.d
M test/unittest/pcap/tst.pcap.stdout-fork-error.sh
M test/unittest/pcap/tst.pcap.stdout.sh
M test/unittest/pcap/tst.pcap.tshark.sh
Log Message:
-----------
Implement the pcap action
The current implementation can only capture the linear portion of
the packet data. Fortunately, this covers the vast majority of all
uses of pcap() anyway.
Future work is needed to be able to access non-linear data for large
packets.
Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
Compare: https://github.com/oracle/dtrace-utils/compare/e4bd14a1ebc8...347ad8afa3a1
More information about the DTrace-devel
mailing list