Sultan Alsawaf [Sat, 31 Oct 2020 07:02:12 +0000 (00:02 -0700)]
stp_task_work: don't busy poll in stp_task_work_exit()
Instead of doing a busy poll and forcefully sleeping for one jiffy every
time stp_task_work_exit() checks to see if all the task workers are
finished, just use a wait event and have the last task worker wake up
stp_task_work_exit() when it's finished. This is faster and more
efficient, since there's no uninterruptible sleeping for exactly one
jiffy at a time, and there's no polling involved.
Alice Zhang [Fri, 30 Oct 2020 06:33:01 +0000 (02:33 -0400)]
PR13838: Added basic floating point support to systemtap
runtime/softfloat.*: including floating point type definition
runtime/softfloat/*: all other required auxiliary functions
These are from https://github.com/ucb-bar/berkeley-softfloat-3
by John R. Hauser, thanks!
tapset/floatingpoing.stp: including fp conversion, fp arithmetic and
comparison functions testsuite/buildok/floatingpoint.stp: including testcase
for corresponding floatingpoing tapset main.cxx: changed sdt_benchmark part
of code for a demo of extracting floating point
Systemtap support 64 bit floating pounint (double type) under ieee754.
Conversions(fp <-> long, fp <-> string), arithmetic(add, sub, div, mul, sqrt)
and comparison between fp(less than, less than or equal to, equal) are
supported, corresponding tapset functions and test case are provided as well.
amerey [Fri, 7 Aug 2020 22:58:33 +0000 (18:58 -0400)]
PR26015: Make syscall arguments writable again
Make syscall arguments writable again in non-DWARF probes on kernels
that use syscall wrappers to pass arguments via pt_regs (currently
x86_64 4.17+ and aarch64 4.19+).
For non-DWARF syscall probes also add an additional probe variable
for each syscall string parameter that holds an unquoted version
of the string parameter. Modifying this variable within the probe
will cause the string it holds to be written to the userspace string
buffer that was passed to the syscall.
Sagar Patel [Thu, 29 Oct 2020 23:34:41 +0000 (19:34 -0400)]
PR26015: Add @probewrite predicate.
The @probewrite predicate checks whether an identifier has been
written to in the probe handler body. The identifier can be either
a script variable or target variable. @probewrite(var) returns 1
if var has been written to in the probe handler body, else 0.
For example,
probe foo = begin { var = 0 }, { if (@probewrite(var)) println(var) }
probe foo { var = 1 }
The @probewrite predicate would resolve to 1 in this case and the
new value of var would be printed.
1) Added probewrite_op.
2) Designed probewrite_evaluator to resolve @probewrite checks.
3) Designed symuse_collecting_visitor (similar to varuse_collecting_visitor).
3) Updated several other visitors accordingly.
4) Added test cases.
5) Updated NEWS.
Sultan Alsawaf [Thu, 29 Oct 2020 18:25:53 +0000 (11:25 -0700)]
task_finder2: change the default engine action to UTRACE_INTERRUPT
There is a race condition where, right after an engine is attached, a
reporting pass will occur before the engine can actually request what it
wants from the target process. In this case, the action that the engine
used when it was first attached will be carried out during the reporting
pass. When the default action is UTRACE_STOP, this means that the
reporting pass will think the newly-attached engine wants to stop the
target process, at which point the target process will be moved into the
TASK_TRACED state (visible via `ps aux | grep ' t '`) and will be
halted forever (until it receives a SIGKILL) because the engine will
never send a UTRACE_RESUME request to bring the target process back to
life. This seems to be an issue with the UTRACE_STOP machinery; it's not
clear how *any* process entering the UTRACE_STOP state can exit that
state naturally. It's also dubious whether the UTRACE_STOP state is even
needed, since tracing is done from within task workers that run inside
the context of the process we're trying to analyze, which allows us to
to safely analyze the process without needing to stop it.
Regardless, it's clear that a newly-attached engine would definitely not
want to stop the process it's trying to analyze; after all, there's
nothing interesting to see if the process is just halted. The common
engine action seems to be UTRACE_INTERRUPT, so let's set that to be the
default instead of UTRACE_STOP.
task_finder2: don't attach to forked children when the target PID is specified
When we have a PID specified for tracing and a fork occurs from our
target PID, the forked child will have the same exe as our target and
will subsequently get matched and attached to by
__stp_utrace_attach_match_filename(). Attaching to these children is not
productive though, since we are only interested in a specific process.
Therefore, as an optimization, only bother trying to attach to forked
children when the target PID is *not* specified. When the target PID is
specified (via -x PID) and match_tsk != path_tsk, we know that a fork
just occurred and match_tsk is the child of path_tsk, in which case
we should just skip attaching to match_tsk.
Sultan Alsawaf [Thu, 29 Oct 2020 08:24:43 +0000 (01:24 -0700)]
task_finder: error out when we cannot attach to _stp_target
In order to avoid sleeping, stap_find_exe_file() does a trylock attempt
on an mm's mmap semaphore and returns NULL when the lock is contented.
When this happens, it can cause the task finder to not attach to a
desired target process. This is especially noticeable when a target PID
is specified, in which case the target PID itself can get skipped over
by the task finder.
Therefore, we should treat failures to get the exe file for a specific
target PID as fatal, since that means the target PID will never get
attached. Note that we must return a negative value from
stap_start_task_finder() in order for the fatal error to be honored, so
we shouldn't negate PTR_ERR(mmpath).
Frank Ch. Eigler [Wed, 28 Oct 2020 00:02:18 +0000 (20:02 -0400)]
testsuite: current.stp module("*") defang
Like for server_concurrency*, the current.stp test case has excessive
debuginfo requirements. We still want -some- decent workload, so
chose usb* as the module wildcard. Far smaller than the "*" there
formerly.
Sultan Alsawaf [Tue, 27 Oct 2020 22:00:49 +0000 (15:00 -0700)]
stp_utrace: replace task_utrace_lock with non-blocking RCU read locks
The global task_utrace_lock is highly contented and results in a lot of
CPU time wasted spinning on it, especially since it's not a r/w lock.
It turns out we can replace all of the task_utrace_lock usage with
non-blocking RCU read locks instead to improve performance. Now, reads
to any of the hash list buckets containing the utrace entries do not
block and can occur concurrently with other readers, and writes to any
hash list won't block readers thanks to the magic of RCU. The only
locking needed is between concurrent writes to a single hash list, and
a per-bucket spin lock is used to achieve this instead of a sprawling
global lock.
Stan Cox [Tue, 27 Oct 2020 15:23:06 +0000 (11:23 -0400)]
Merge branch 'scox/tls': Add tls support.
This merges support for accessing implicit tls variables.
Given a DW_OP_GNU_push_tls_address dwarf entry,
tls.stp::__push_tls_address handles navigating the tls data
structures. stp_tls.h contains minimal versions of a few essential
tls data structures.
Frank Ch. Eigler [Tue, 27 Oct 2020 02:01:24 +0000 (22:01 -0400)]
step-prep: check for debuginfod capability
Test /usr/bin/debuginfod-find for a vdso*so in the kernel. If
successful, avoid downloading big kernel debuginfo files now,
assuming that the debuginfo server(s) will remain available.
fs/kernel_file_read: Add "offset" arg for partial reads
To perform partial reads, callers of kernel_read_file*() must have a
non-NULL file_size argument and a preallocated buffer. The new "offset"
argument can then be used to seek to specific locations in the file to
fill the buffer to, at most, "buf_size" per call.
Where possible, the LSM hooks can report whether a full file has been
read or not so that the contents can be reasoned about.
This and the preceding commits changed the function signature from:
To fight the oobleck of giant test log files (ok to store with Bunsen
but hard to display in a browser without pagination tricks), reduce
the most verbose testcases.
unprivileged_embedded_C.exp bombards us with pass2 output.
(Always printed even without -v flag.)
Options:
1) suppress stap stdout but not stderr with sh -c wrapper + redirection
2) separate and drop stdout in the expect script (not feasible)
3) add a secret --silent-p2 option to stap which drops pass2 output
Sultan Alsawaf [Thu, 22 Oct 2020 04:50:16 +0000 (21:50 -0700)]
task_finder_vma: add autoconf check for atomic_fetch_add_unless()
Some kernels have atomic_fetch_add_unless() backported, such as
4.18.0-240.5.el8.aarch64 and 4.18.0-193.28.1.el8_2.x86_64 on rhel8,
so we cannot rely on the kernel version to determine whether or not
the function is present. Add an autoconf stub to check for it.
Optimize: increase the default size of the vma map hash table
Hash conflicts is severe when the vma tracker keeps track of many
processes given the current hash table size of mere 16 buckets.
Increased it to 256 buckets by default and also make it tunable
via the macro __STP_TF_HASH_BITS.
In our test, this significantly reduces hash conflicts when
stap/staprun's -x PID option is not specified.
Sultan Alsawaf [Wed, 21 Oct 2020 19:27:24 +0000 (12:27 -0700)]
task_finder_vma: rewrite using RCU to fix performance issues
The use of a single global rwlock to protect this file's hash table
results in significantly degraded performance when there are many
processes using the vma tracker in flight. A lot of time is spent
spinning on the rwlock when this happens. For exmaple, it is using
most of the CPU time in the following kernel-space CPU flame graph:
There are other code paths which would invoke the same spinlock, as in
_stp_umodule_relocate().
To remedy this, make the hash table RCU safe so we'll never block upon
reading a hash list.
We now use the hash_ptr() function to generate the hashes, and the task
pointers themselves are hashed now instead of their PID for reliability,
since PIDs are not a stable anchor point to a task struct.
While we're at it, clean up the rest of this file to bring it up to
current Linux kernel coding standards as well.
This leads to dramatic CPU time reduction when
1. the current system has a lot of running processes, or
2. some processes have a lot of DSO dependencies, and
3. also -x PID is not used for stap or staprun, and
4. there are quite a few CPU cores.
For a typical test run, we have the following CPU utilization changes:
Serhei Makarov [Wed, 21 Oct 2020 20:06:48 +0000 (16:06 -0400)]
PR26755 temporary kprobes_onthefly.exp: also disable m* on ppc
XXX Need to investigate which of the tracepoints under m* is failing. XXX
For now, blacklist these in kprobes_onthefly.exp to allow the buildbot
testsuite to finish running.
An onthefly testcase started freezing the kernel on the 'hardcore'
case which grabs lock:lock_{acquire,acquired,release,contended} tracepoints.
I'm still tracking down which kernel change caused this
since the tracepoints exist on older codebases (probably lockdep kernels),
but for now it seems that we should avoid probing these in onthefly testing.
Stan Cox [Fri, 9 Oct 2020 20:51:57 +0000 (16:51 -0400)]
Support tls on ppcle
Support tls on ppcle as described in "OpenPOWER ABI for Linux Supplement
Power Architecture 64-Bit ELF V2 ABI." Use glibc debuginfo instead of constant
offset to access link_map->l_tls_modid. Remove set_tls_module_by_addr.
Sultan Alsawaf [Thu, 1 Oct 2020 22:19:47 +0000 (15:19 -0700)]
PR26697: fix NULL pointer deref in get_utrace_lock()
task_utrace_struct() can return NULL via __task_utrace_struct(). This fixes
the following crash:
BUG: unable to handle kernel NULL pointer dereference at (null)
#9 [ffff8843e56ffd20] get_utrace_lock at ffffffffc08258c6 [stap_X_40544]
The reason why it can return NULL is because engine->ops is protected by
utrace->lock, but we don't have the utrace pointer, and the purpose of
get_utrace_lock() is to get the utrace pointer. Therefore, there's no way
to ensure engine->ops remains unchanged inside get_utrace_lock(), so
get_utrace_lock()'s checks on engine->ops can be incorrect/stale, which
leads to the NULL pointer dereference.
Previous logic for detecting whether module-signing was required
was broken by the presence of non-systemtap MOK keys. This led
the client to find no matching stap-servers, leading to no
compilation attempt or MOK assignment. New code filters local
MOK keys for Systemtap ones only, and even in an absence,
communicates the need for a signature via a "missing" marker.
The server eagerly passes back (new or old) MOK keys to such a
client now.
Tested on a rhel8 uefi/secureboot kvm vm. Transport /sys/debug
dependencies are still blocking full function due to kernel_lockdown,
but that's coming next.
tentative fix: update hand-written Makefiles to use KBUILD_EXTMOD=
kernel 5.3+ deprecated and then removed the SUBDIRS=
flag for building an external module. In conjunction with KDIR=,
this led to unpredictable results (i.e. a build failure which
would delete the system kernel-devel package's config files (!)).
Commit 0126be38d9 counsels to use M= or KBUILD_EXTMOD= instead.
No harm in specifying both since newer kernels should ignore SUBDIRS=
The rhel4 era (<2.6.15) relayfs transport hasn't been tested for stap
releases in many years, and appears to have no compelling reason to
keep the code around. Let's remove the code.
The non-default ring_buffer transport hasn't even compiled in some
time, and appears to have no compelling reason to keep the code
around. Let's remove the code.
Frank Ch. Eigler [Thu, 27 Aug 2020 17:05:43 +0000 (13:05 -0400)]
man stap.1: belatedly mention type auto-casting
Way back in 2014, starting with 0fb0cac98ad48, an auto-casting
facility was added. This allows context-variable derived pointers to
retain their type information as the pointers are moved around inside
systemtap integer variables & expressions. This was only documented
in the 2.6 release NEWS. Now it's in the man page too.
1) In semantic_pass_optimize1, preserve synthetic probes even with
empty bodies, which would normally be elided. This allows
probe-conditions to be more properly initialized, and
initially-false probes to be disarmed early.
2) In c_unparser::emit_probe(), call emit_lock() based on the
needs_global_locks() lockworthiness of the proper probe (the
derived_probe being translated, rather than the other derived_probe
whose conditions are being evaluated)
This lets the new lock-pushdown.* tests work with or without -u (now
tested).
Frank Ch. Eigler [Mon, 17 Aug 2020 19:49:35 +0000 (15:49 -0400)]
PR26296: lock pushdown optimization
Implements an algorithm to push lock/unlock operations downward in the
syntax tree, to just enclose the smallest possible region that deals
with global variables. This means two common patterns run with much more
concurrency than before:
global a
probe foo {
if (condition)
{ a++ }
else
{ something_else() }
}
will only lock globals -if- the condition is true, so something_else()
would run unlocked. Also:
global a
probe foo {
if (a)
{ long_twisty_operation(); }
}
will unlock globals right after the condition is evaluated, so
long_twisty runs unlocked. Previous behaviour is avilable with
--compatible=4.3. New test case lock-pushdown.stp asserts locking
conditions throughout various relevant constructs.
PR26392: removed the "stable" flag from unwunding tapset functions
By design, stable function calls should be lightweight ones like pid()
and target(). unwinding functions like ubacktrace() are kinda expensive.
And marking them as stable calls would make them get always evaluated no
matter what.
William Cohen [Wed, 5 Aug 2020 13:43:17 +0000 (09:43 -0400)]
Make dtrace generated code work with LTO (take 2)
LTO needs to know which variables might be accessed by code. In sdt.h
there is a fair amount of assembly code which LTO cannot analyze. As
a result LTO would assume that the semaphores variables for various
userspace probes were not accessed by the generated code. The linking
would fail because LTO would optimize away the semphore variables
causing undefined references.
The fix adds the semaphore variables as input operands to the assembly
statements. This gives the LTO analyzer information that the
variables are used within the assembly statements and should not be
removed.
PR26307: adapt to kernel module_sect_attr changes in 5.8+
Linux v5.8 rc5ish, commit ed66f991bb19, introduced a change to the
internal module_sect_attr types. It caused a kernel BUG: with
pr14546.exp. This showed it's futile to keep chasing it this
particular way in runtime/transport/symbols.c, so for new enough
kernels (4.7+), a method based on
kernel_read_file_from_path("/sys/module/$MODULE/sections/$SECTION") is
used to extract module section base-addresses.
This is done by a new paper-thin abstraction. Tested on RHEL7, F32,
rawhide.
PR26249: "%p" -> "0x%lx" pointer formatting in *conversions.stp error messages
function::user_string() and function::user_string_warn() in uconversions.stp
were passing an "unsigned long" to the "%p" format-specifier, which upset gcc10.
Switch to 0x%lx. In the process, change other uses of %p to use 0x%lx instead,
changing casts from (void*) to (unsigned long) where necessary.
Fixes the following error on gcc10 (Fedora 32):
In function ‘function___global_user_string_n_warn__overload_1’:
/tmp/stapXXXXXX/stap_[...]_src.c: error: format ‘%lx’ expects
argument of type ‘long unsigned int’, but argument 5 has type
‘void *’ [-Werror=format=]
PR25568 / RHBZ1857749: buildid/uprobes/inode rework, task_finder etc. side
During work on a new stress tests for build-id based probes (coming in
next commit), it was found that the task_finder2 logic for buildid
verification didn't, well, work, because it was never run (due to an
erroneous pathlen conditional), and couldn't be safely run where it
was (because it was under spinlock but would have done
access_process_vm). Reworked the relevant bits of task_finder2 to
perform build-id verification for processes later - during the quiesce
callback periods. (Buildid verification for solibs is already done
in the task_finder2 consumer uprobes-inode.c.)
Testing with sdt_misc indicated a case where a preexisting process
(with solib sdt.h semaphores) was being attached to by a new stap
binary. task_finder2's enumeration of the preexising processes'
memory map segments violated assumptions by recent code related to
tracking in stapiu_process[] lists. (It did not mirror the temporal
ld.so mmap sequence.) Changed this tracking to use the inode* as the
key, and stop trying to track mapping lengths, to make positive
matches and eliminate duplicate stapiu_process[] entries for the same
(process,solib) permutation. Reworked stapiu_process[] accumulation
generally to move to the two immediate task_finder callbacks, out of
stapiu_change_plus().
Added lots of commentary and diagnostics throughout. stap
-DDEBUG_UPROBES give meaningful info about uprobes & sdt semaphores;
with -DDEBUG_TASK_FINDER, more but not overwhelming relevant info
appears.
rhbz1857749: uprobes-inode regression in sdt semaphore setting
Previous code neglected to set sdt.h semaphores for more than the
first process systemtap happened to encounter. This was from a
mistaken understanding of what it meant for stapiu_change_plus() to be
called with the same inode/consumer combination. Even though uprobes
are automatically shared, each new process still needs its perfctr and
sdt-semaphores individually set, so we do that now (as before the
rework of this code). Mechanized testing incoming shortly.
configury: make systemtap buildable with gcc -flto
Two problems corrected:
1 - Some of the stap object files compiled the interned_string type
differently based on whether config.h was #included early enough
or not. Now they all do it at the top.
2 - The staprun/libstrfloctime.a pseudo-archive (added in commit 0a5f4aa83e5b4 to work around an autoconf limitation), needs a
-Wl,--whole-archive wrapper around it for lto linking purposes.
Now also stap builds on f32 both with and without:
William Cohen [Tue, 14 Jul 2020 20:36:24 +0000 (16:36 -0400)]
Make dtrace generated code work with LTO
LTO will attempt to remove variables if they are not clearly as used
in assembly code and the linking will fail with errors about undefined
variables. The semaphores variables in the sdt.h macros need to be
marked as global to ensure that LTO doesn't incorrect remove them.
William Cohen [Mon, 13 Jul 2020 20:10:22 +0000 (16:10 -0400)]
Make dtrace generated code work with LTO
When variables are marked with the unused attribute LTO will attempt
to remove variables when they are only used by assembly code. Marking
the semaphores variables generated by the dtrace with the used
attribute will ensure that LTO doesn't incorrect remove them.
PR26234: stapbpf should warn about unsupported utrace_derived_probes
Probes such as process.begin are handled by task_finder, which is
not supported by BPF. Until some workaround is found, print
a warning instead of silently ignoring the probes.
testsuite: block listing_mode_sanity large tests on small machine
Use a /proc/meminfo based heuristic to block two particularly
cpu/ram-costly tests on small machines, for same reasons as we nuked
semok/twenty.stp some time ago.
RHBZ1847676 cont'd: one more uprobes-inode/onthefly concurrency control
In uprobes-inode.c (stapiu_change_plus), the runtime can react to
arrivals of new mappings of a solib or executable by registering new
uprobes. Due to an assumption that this could not happen at
inconvenient times (such as a stapiu_refresh or near shutdown times),
the actual uprobes registration operation was done outside the
consumer_lock mutex being held. But it appears this can happen at bad
times, so the mutex needs to be held, just like within
stapiu_consumer_refresh().
The onthefly tests now survive iterating testing on rawhide+lockdep
and rhel7+lockdep.
On recent kernels, printk("...%p...") pointers are obfuscated by
default. Tweak the systemtap startup dmesg to present a real pointer
(via "%lx"), which is essential for troubleshooting.
run-stap.in: forget about bundled elfutils build mode
The "run-stap" script in the build tree allows developers to run
a freshly built, un-installed copy of systemtap. It still knew of
our former bundled-elfutils build mode. That has been removed,
so this logic is now gone from this script.
PR25549: statement probe visibility for openmp / lto binaries
gcc -flto and -fopenmp can synthesize function bodies that may miss
DWARF attributes such as AT_decl_file. Previously, systemtap included
a check to match the value of that attribute against a list of file
names extracted from the source-file directory, and would reject any
function DIE that doesn't match. So these -flto/-fopenmp functions
were invisible to systemtap probes. We now override this for the case
for functions that completely lack that attribute, to expose these to
normal dwarfy probing. New test case included (using -fopenmp).
Martin Cermak [Thu, 9 Jul 2020 07:19:01 +0000 (09:19 +0200)]
Tapset and testsuite updates against @cast() change 00ee19ff03
Commit 00ee19ff030f665df7e087a579f39105256a0253 changed how @cast()
operations work and they no longer default to using the kernel
debuginfo for type information. Need to include kernel as location for
this information for the @cast() rather than just assuming a default.
These are respective tapset and testsuite minor updates.
RHBZ1847676 cont'd: more uprobes-inode/onthefly concurrency controls
The systemtap.onthefly/*.exp tests had recently become hang-prone on
some kernels, for reasons still not completely understood. This set
of patches adds:
- irq*-block spinlocks into uprobes-invoked paths, in case there is
peculiar reentrancy (from irq-related tracepoints)
- a mutex lock/unlock into the stapiu_exit() path, in case there is
a concurrent stapiu_refresh() invoked by onthefly machinery around
exit time
- restrictions into the onthefly module_refresh() translator code to
preclude STAP_SESSION_STOPPING as a time to do any sort of refresh
operation. Now probes that were disarmed will stay disarmed during
probe-end/error/etc. processing, which is always valid with the
spec, and avoids a class of late module-refresh ops
Testing on rhel7 and rawhide indicates the reproducible hang is gone.
Our testsuite already tortures this code; invoke by hand via:
% sudo make installcheck RUNTESTFLAGS="-v affection.exp hrtimer_onthefly.exp kprobes_onthefly.exp tracepoint_onthefly.exp uprobes_onthefly.exp"
Some versions of gcc complain about an error-message
formatting mismatch:
'probe begin {println(user_string_n_warn(0, 20)) }'
->
/var/tmp/stapk2aFPs/stap_b9f8a6b29bbfa7f7e051c7587bbf7762_1907_src.c:288:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘void *’ [-Werror=format=]
288 | "user string copy fault 0x%ld at %lx [man error::fault]", rc,
This switches to "0x%lx", (uintptr_t) consistently in related functions.
Frank Ch. Eigler [Tue, 30 Jun 2020 23:04:16 +0000 (19:04 -0400)]
PR26142: adapt to linux mmap_sem api transition
With upstream linux 5.8-bound commit da1c55f1b27, the
mm_struct->mmap_sem field is renamed, and a new <mmap_lock.h> api is
introduced to lock/unlock it. Adapting only the most recent runtime
parts (task_finder2.c and access_process_vm.h) to the new api by
providing autoconf-driven macro wrappers. Other
backward-compatibility parts of the stap runtime still use mmap_sem,
but those are only compiled on old kernels, so don't appear to need
this porting. Tested on 5.8.0-0.rc2.20200626git4a21185cda0f.1.fc33.x86_64
and 5.6.19-300.fc32.x86_64.
Frank Ch. Eigler [Tue, 30 Jun 2020 19:24:18 +0000 (15:24 -0400)]
PR26142: Adapt to linux/vermagic.h file hiding
Linux commit 51161bfc66a68 (2020-04-19) enforces a convention of not
including <linux/vermagic.h> from normal source files. Switch to
<generated/utsrelease.h>, which has UTS_RELEASE, which is all that we
really wanted anyway.
Martin Cermak [Mon, 29 Jun 2020 14:30:34 +0000 (16:30 +0200)]
PR26181: Use explicit @cast() within get_ip_from_client()
Commit 00ee19ff030f665df7e087a579f39105256a0253 changed how @cast()
operations work and they no longer default to using the kernel
debuginfo for type information. Need to include kernel as location for
this information for the @cast() rather than just assuming a default.
Also, fix the type of server_ip, which historically had been a long,
but since systemtap_v >= "4.3", it is a string.
William Cohen [Mon, 22 Jun 2020 15:28:32 +0000 (11:28 -0400)]
Use explicit @cast() operators pointing to kernel for tapsets
Commit 00ee19ff030f665df7e087a579f39105256a0253 changed how @cast()
operations work and they no longer default to using the kernel
debuginfo for type information. Need to include kernel as location for
this information for the @cast() rather than just assuming a default.
git://sourceware.org / systemtap.git / log