bpf.exp: tentative fix for bigmap1.stp hang on RHEL8

Experimentation with the prior bigmap1.stp patch
shows that bpf.exp may need a stronger kill -KILL to
avoid waiting for a stuck process.

Not sure why this wasn't done in the first place,
the comment suggests kill -KILL but the code does kill -INT.

RHBZ1847676: uprobes-inode tweaks redux

Added (back) a spinlock to manage the stapiu_consumer -> process_list
structure, since it is occasionally travered from uprobe pre-handlers,
which are sometimes entered in atomic context (e.g. on rhel7).  There,
the normal mutex_t is unsafe.  So restoring a spinlock_t just for
those shortlived traversals, rhel7 and rawhide are both happy.

Make sizeof.stp runnable with the bpf backend.

remove comment

PR26123: fixed memory leaks in vma map for kernels without CONFIG_UTRACE.

Add overcommit.stp to examples that can run in bpf.

configury: post-release version bump

Avoid exceeding space constraints for the BPF environment in mmfilepage.stp

The BPF runtime environment is very space constraint.  The
mmfilepage.stp example has been reorganized to reduce the stack space
and number of BPF registers needed to run the code to allow the
generated BPF code to fit within the constraints.

Avoid exceeding space constraints for BPF environment in mmwriteback.stp

BPF is very contrained on the space allowed when running the code.
Using too complicated printf statements caused too much stack space to
be used for temporaries and the stap compile would fail for the BPF
backend.  Replacing the complicated printf with simpler string printf
statements uses less stack space and allows the BPF backend to compile
this example.

prerelease: update-docs

docs generator: tweak for python3

prerelease: PRERELEASE source bumps

prerelease: AUTHORS bump

prerelease: update-po

tapset: fix ctime.stp handling of STAPCONF_TIME32_OLD_H

We need a type alias that works for ctime.stp even if the #defines
in aux_syscalls.stp were not already pulled in.

bpf-translate.cxx: avoid dereferencing empty vectors

Under some conditions, a bpf translation-pass vector could be read
empty.  We check better.

PR26019 stapbpf: don't continue startup if begin probe already exited

if a bpf begin probe sets exit status, the main thread will skip the
pause() call and immediately deallocate global data structures. Then
the perf_event_loop thread will run on the corrupted data and
occasionally fail. Example result is an assertion failure due
count_active_cpus() running on corrupted data.

Could change the main thread to join() instead of detach(), but then
all threads must be modified to listen for exit status including exit
status from begin thread. TODO Consider doing so later.

I think if the begin probe was running, it wasn't correct to start the
perf_event_loop (or PERF_EVENT_IOC_ENABLE, or any of the procfs
threads) in the first place, as those things logically happen after
the begin probe has already exited. Simply clean up and exit.

uprobes-inode: rework for buildid vs. onthefly work

Tweak locking in the cleanup paths. stapiu_consumer_unreg (at
stap exit time) now does all cleanup, including its process_list,
and stapiu_change_minus (at probed process exit) does nothing.
This seems to strike a good balance between cheering up lockdep
and using a little more memory during very long-lived stap jobs.

uprobes-inode: rework for buildid vs. onthefly work

Addition of the buildid-based probes has highlighted some weaknesses
in the uprobes-inode code with respect to the interlinking & sharing
of various tracking data structures.  This patch reworks the code to
simplify and document.  The uprobes_onthefly.exp test case easily
survives now.

gcc compatibility: use gcc #pragma to suppress -Wtautological-compare

On some compilers / distros, the kbuild-flavour cc-options runtime
test for suppressing -Wtautological-compare does not work.  So we
switch to a pragama based suppression that works as far back as rhel7
gcc 4.8.5.  We need to suppress that warning because script-originated
generated code can easily include tautologies.

PR26074 fixup: disable #else paths on !USE_KALLSYMS_ON_EACH_SYMBOL

These previously #else paths should only be taken if
USE_KALLSYMS_ON_EACH_SYMBOL does not hold, not if
USE_KALLSYMS_ON_EACH_SYMBOL is true but the runtime condition is
false.

session.cxx prerelease: declare support for kernel 5.7

PR26099: adapt to struct proc_ops split from struct file_operations

Linux kernel commit d56c0d45f0e for version 5.6 made the following changes:
- procfs functions now take struct proc_ops instead of struct file_operations
- proc_dir_entry now has union{proc_ops,proc_dir_ops} instead of proc_fops

struct proc_ops is newly declared in the commit, so we test for its presence.

* buildrun.cxx (compile_pass): Introduce STAPCONF_PROC_OPS.
* runtime/linux/autoconf-proc-ops.c: New file. Test for struct proc_ops.

* runtime/procfs-probes.c (_stp_proc_fops): Declare as proc_ops when available.
* runtime/procfs.c (_stp_create_procfs): Take fops as proc_ops when available.
* runtime/transport/control.h (_stp_ctl_proc_ops.cmd): New proc_ops version of
_stp_ctl_fops_cmd for use
* runtime/transport/control.c (_stp_ctl_proc_ops.cmd): Ditto.
* runtime/transport/procfs.c (_stp_proc_fops): Declare as proc_ops when available.
(_stp_register_ctl_channel): struct proc_dir_entry renamed proc_fops to proc_ops,
adapt in two locations.

man error::dwar7: mention kbuild -fno-var-tracking-assignments

"The simplest fix is to erase, excise, nay, eradicate this"

Add probes to container_check.stp for additional capabilities checks

Probe points were added for ns_capable_noaudit, ns_capable_setid,
and file_ns_capable functions.  Before adding these probes some
capability checks were missed by the container_check.stp script.
This was observed running the script on DPDK testpmd.

Bug: __stp_tf_quiesce_worker(): vma mmap callback incorrecty ran after process.begin callback

feature: vma-related primitives now work in process.begin.

Bug: tapset functions reading userland registers did not work in probe process.begin

PR26074: pass kallsyms_lookup_name as a relocation to the stap runtime

Kernel commit 0bd476e6c671 unexports kallsyms_lookup_name
and kallsyms_on_each_symbol.
As kallsyms_lookup_name is used to look up unexported symbols, we need to
use the relocation mechanism (the same one used to pass _stext) to pass
these symbols to the runtime where necessary.

The patch preserves the old behaviour (link the exported symbol directly)
where kallsyms_lookup_name is available.

* buildrun.cxx (compile_pass): Change output_autoconf
STAPCONF_KALLSYMS_ON_EACH_SYMBOL to exportconf
STAPCONF_KALLSYMS_ON_EACH_SYMBOL_EXPORTED. Since the symbol may be
accessed even when unexported, the autoconf-kallsyms-on-each-symbol.c
is no longer accurate. Control the powerpc issue (PR11514) with
appropriate #ifdefs instead.
Change STAPCONF_KALLSYMS to STAPCONF_KALLSYMS_LOOKUP_NAME_EXPORTED.
* runtime/linux/autoconf-kallsyms-on-each-symbol.c: Deleted.

* runtime/linux/runtime.h (_stp_kallsyms_lookup_name): New field.
(_stp_kallsyms_on_each_symbol): New field.
* runtime/sym.c (kallsyms_lookup_name_fn): New typedef.
(kallsyms_lookup_name): New function, linked in place
of kallsyms_lookup_name, calls _stp_kallsyms_lookup_name if available.
(kallsyms_on_each_symbol_fn): New typedef.
(kallsyms_on_each_symbol): New function, linked in place of
kallsyms_on_each_symbol, calls _stp_kallsyms_on_each_symbol if available.

* runtime/sym.h (_stp_need_kallsyms_stext): New field.
(_stp_set_stext): New function, called to adjust _stp_kretprobe_trampoline
if kallsyms_lookup_name("_stext") call is delayed until after the relocation
is received.
* runtime/transport/symbols.c (_stp_set_stext): New function.
(_stp_do_relocation): Set _stp_kretprobe_trampoline if kallsyms_lookup_name
is not yet available,
Accept and set _stp_kallsyms_lookup_name and _stp_kallsyms_lookup_symbol
from relocations.
* runtime/transport/transport.h (_stp_handle_kallsyms_lookups): New function,
does delayed kallsyms_lookup_name() lookups previously done
in _stp_transport_init(), does delayed _stext lookup.
* runtime/transport/transport.c: Include sym.h for _stp_set_stext().
(_stp_handle_kallsyms_lookups): New function.
(_stp_transport_init): Don't do kallsyms_lookup_name() lookups yet
as kallsyms_lookup_name may be passed later on via relocation.
Init the addresses and _stp_need_kallsyms_stext to NULL instead.
* translate.cxx (c_unparser::emit_module_init): Emit a call to
_stp_handle_kallsyms_lookups() into systemtap_module_init(),
where the relocations for kallsyms_lookup_name() will be available.
* staprun/staprun.c (send_relocation_kernel): Look up
kallsyms_lookup_name and kallsyms_on_each_symbol in /proc/kallsyms
and send their addresses as STP_RELOCATION messages.

* runtime/linux/kprobes.c: define USE_KALLSYMS_ON_EACH_SYMBOL.
May be determined statically or dynamically depending on whether
a relocation is necessary to call kallsyms_on_each_symbol.
(stapkp_prepare_kprobe): change #ifdef to if(USE_KALLSYMS_ON_EACH_SYMBOL).
(stapkp_prepare_kretprobe): Ditto.
(stapkp_symbol_data): make available in all circumstances.
(stapkp_init): change #ifdef to if(USE_KALLSYMS_ON_EACH_SYMBOL).
(stapkp_refresh): Ditto.

* runtime/transport/transport_msgs.h (enum): clarifying comment
for STP_RELOCATION message.

configury: adjust -lebl check to ebl_strtabinit

While -lebl has been integrated into -ldw in recent versions of
elfutils, some older versions need a better aimed check, for
the exact symbol that bpf-translate.cxx uses.

move the new added blurb under version 4.3

update blurb related to PR13793

RHBZ1842866 kernel-rt port: treat CONFIG_PREEMPT_RT as if ..._FULL

Until recently CONFIG_PREEMPT_RT_FULL was the config switch used by
PREEMPT_RT (and RHEL-RT up to 8.2) for building an RT kernel.
Upstream commit a50a3f4b6a313 ("sched/rt, Kconfig: Introduce
CONFIG_PREEMPT_RT") changed that to be CONFIG_PREEMPT_RT.

rename nfs_proc-embedded-newver with specific version indicated

Fix PR13793

* tapset/linux/nfs_proc.stp: fix get_ip_from_client typo

Fix PR13793 by adding IPv6 support nfs_proc.stp

* tapset/linux/nfs_proc.stp: Updated get_ip_from_client and get_ip with IPv6 support for version after 4.3
* testsuite/buildok/nfs_proc-embedded.stp: Fix probe point so that embedded-C would work properly. Support version before 4.2.
* testsuite/buildok/nfs_proc-embedded-newver.stp: nfs_proc-embedded test case that supports version after 4.3.
* testsuite/buildok/rpc-embedded.stp: Fix probe point so that embedded-C would work properly.

update foreach loop test

runtime/tapset: adapt to more time32 kernel deprecation

Linux commit 412c53a6 et al., deprecate various 32-bit time-related
types/structs.  Many are replaced by userspace-compatibility types
under different names ("old_*") in a different header, so we #include
that.  In order to keep the runtime code as unchanged as possible, we
add some of the name-mapping macros into our own embedded-C code.

Tested on f31, rhel7.

testsuite abort.exp: adapt to tweaked error message

Unresolved-function semantic errors now print something extra.

syscall tapset: _do_fork args conversion

As of linux 5.3 commit 7f192e3cd316ba, the _do_fork() function probed
for syscall.clone switched its API to carry arguments curried in a
struct.  Adjusting the syscall.clone tapset to accept either API
via the @choose_defined() macro.

warnings: don't complain about cross-file global var access within tapset

The syscall.* tapset uses this construct

tapset/linux/syscalls_cfg_trunc.stp:global syscall_string_trunc = 50

to configure pretty-printing.  There's no need to warn about
unintentional cross-file global var accesses in this case.
So the warning is restricted to tapsets matching with user-script
globals only.

PR14013: don't reject DW_OP_GNU_push_tls_address DWARF location operator

Subject DWARF OP is used for accessing TLS variables in GCC-compiled C
code.  In all but the simplest cases, we must emulate libthread_db
logic for resolving TLS addresses.  Step 1 is to map this operator to
a tapset function call __push_tls_address, which will implement the
architecture-specific lookup functionality.

We also tweak systemtap_session::print_error to ensure even isolated
little error messages seen only once do get printed.

See also: https://infinitynotes.org/wiki/Glibc

translator: ditch one assert(0)

In translator_output::assert_0_indent(), we used to assert(0) if
something went wrong with the translation process that resulted in the
generation of incorrectly nested C code.  We could emit a warning or a
runtime_error or something, but even doing nothing is OK, since a
pass-4 error will surely follow.

Correct error counting error in systemtap_session::print_error()

Logic such as

  if (verbose > 0 || seen_errors[pe.errsrc_chain()]++ < 1)

short-cirtuits the increment of seen_errors[] in verbose mode.
This can lead systemtap_session::num_errors() to return 0 (!!)
even if errors occurred, which can in turn lead to later passes
being attempted.  This sort of thing is nuked in two places,
to look thusly instead:

  if (verbose > 0 || seen_errors[pe.errsrc_chain()] < 1)
    {
      seen_errors[pe.errsrc_chain()]++;
      ....
    }

The above problematic pattern was introduced by some guy in commit
0e1d5b7eb39785cb.  He should never again be allowed near computers.

bigmap1.stp: tetentative fix for a hang on RHEL8

My suspicion is that the vfs_read probe was not triggering sufficiently often,
causing the script to keep running (and the subsequent attempt to kill it failed).
Added an extra probe within the testcase to time out after a while.

If it doesn't work, the in-testcase timeout should be further reduced.

XXX The failure to kill the process needs further investigation. It
was possible at one point to get a hang like this in the userspace
interpreter, but I'm unsure of the reason it's happening here and now.

PR11599: fix buildid function & mark probes for stap list/run purposes

Listing mode and sdt derived probes muck with the understanding of the
new buildid probe points, since the process("....") argument string is
internally sometimes an exemplar executable name, and sometimes just
the buildid.  (Too bad it's not easy to track what is what -- and we
even have code like dwarf_query::mount_well_formed_probe_point which
temporarily rewrites previously hand-crafted probe point arguments.)

This current set of changes seems to be the minimum to make all these
work & retain the buildid hexcode:

stap -vL 'process(BUILDID).mark("*")'
stap -vL 'process(BUILDID).function("*")'
stap -L 'process(BUILDID).mark("*")'
stap -L 'process(BUILDID).function("*")'
stap 'process(BUILDID).mark("*")'
stap 'process(BUILDID).function("*")'

PR11599: tweak macro for F31

runtime/linux/stp_tracepoint.h's fallback definition of
STAPCONF_TRACEPOINT_HAS_DATA needs to match the stapconf-generated
one - now they both define explicitly as 1, so they don't evoke
conflicting macro setting errors.

NEWS: mention process buildid probes

util.cxx: Add function is_build_id()

Determines whether a string is a build-id. For the purposes of
this function, a string is considered a build-id when it consists
only of lowercase hex digits and has a length greater than 2.

PR11599: fix prototype for prev commit

PR11599: update STAPCONF_TRACEPOINT_HAS_DATA to work with kernel 5.7.0+

Until 2.6.35 (commit 38516ab59fbc5b), register_trace_* took one argument.
Until 5.7.0 (commit a2806ef77ff9a9), this could be checked by checking
for the absence of DECLARE_TRACE_NOARGS. Now _NOARGS variant is
removed, and we need to add an autoconf program to check the
register_trace_* function directly.

Add missing debuginfod_CFLAGS/_LIBS to all binaries built with util.cxx

PR25568: Add buildid-based process probes

Specify the targets of process probes using the build-id
of the target executable: 'probe process("BUILDID").*'.
BUILDID should be prefixed with '0x' to distinguish it
from a filename.

To find an executable with BUILDID stap will check
/usr/lib/.build-id. If the file cannot be found and
debuginfod is enabled, stap will also query debuginfod
for the executable.

NEWS: worth explaining PR10280

PR10280: fix 'ISO C90 forbids mixed declarations and code'

PR10280 fix prev commit: UTS_RELEASE is vacuous, UTS_VERSION is not

The comparison of UTS_RELEASE vs session->kernel_release used two
compile-time values and not the values in the running kernel for both
sides of the comparison. Hence vacuous.

Now disabled by default, can be re-enabled with STP_FULL_VERREL_CHECK.
Previously enabled, could be disabled with STP_NO_VERREL_CHECK.

UTS_VERSION vs utsname()->version is still compared, where available.
Still enabled, can be disabled with STP_NO_VERREL_CHECK.

PR10280: disable vacuous UTS_VERSION/UTS_RELEASE checks

The comparisons of UTS_VERSION vs utsname()->version used compile-time
values and not the values in the running kernel for both sides of the
comparison. Hence vacuous.

Now disabled by default, can be re-enabled with STP_ENABLE_VERREL_CHECK.
Were previously enabled, could be disabled with STP_NO_VERREL_CHECK.

PR10280: re-enable 'force vermagic for guru-mode scripts'

Current version checking based on kernel ABI and build-ids is not
strict enough to prevent launching a stap module on a kernel version
it wasn't compiled for. This has the potential to crash a running
kernel, since ABI compatibility may not give a sufficient guarantee of
real compatibility.

This patch was reported to cause problems on a PPC machine, but the
reasons are still unclear. Worksforme with the PPC machine I tested it on,
but there are kernel patches that suggest the vermagic string may be
additionally mangled (43e24e83f35).

Re-enabling this and will cautiously monitor the aftermath.

PR25579: look for new /sys/kernel/security/lockdown for mod-signing

Extend systemtap_session::modules_must_be_signed to look for activated
integrity or confidentiality mode to activate secureboot-related
module-signing logic.

PR25841: rhel7 python3.6 porting

Some final minor tweaks for _HelperSDT.c to contain python dwarf.

PR25841: python2+3 exploitation

Reworking aspects of the python tapset & translator logic to make it
work again, after an extended period away from the plantation.  This
involved several bits:

Let all the the python[23].stp tapset functions use @cast()s that
extract debuginfo from the invoking HelperSDT.so file, not from some
always-obsolete list of libpython.so file names.  This was enabled by
the per-probe-point cloning features pulled in recent commits.  This
requires the _HelperSDT.c file to include the DWARF data normally
pulled from libpython, which is easy ... except for a few libpython3.7
internal data structures related to dicts.  Those few decls are
copy-and-pasted (eww).  python 3.6 support will need tweaks.

The python_{print,sprint} backtrace() functions are now provided
directly by the python[23].stp tapsets, as overloaded functions.  They
determine the eligibility by testing $$$$provider against "HelperSDT2"
or "HelperSDT3" to identify the python version in effect in the
invoking python extension .so.  The $$$$FOOBAR syntax is an
undocumented (sssh!) escape hatch for tapset functions invoked from
python*.module* probes which, to bypass one round of python $context
var expansion, and to land in the second round of sys/sdt.h $context
var expansion.

This relies on dead_control_remover being run eagerly & early during
symbol resolution, just as const folding, to eliminate unreachable
code.  (Letting python3 HelperSDT.so functions try to resolve python2
data types would fail during pass 2.)

The generated procfs("_stp_python*_probes") {} probes now have a dummy
exit() body, so that probe-with-empty-body elision added in 2019 keeps
them.

runtime/sym.c: fixed NULL ptr deref bug in m->path

This is a followup fix for commit 6ec3b7c022b.

Kernel panic might occur on CentOS 6 due to this bug. One typical kernel
crash looks like this:

https://gist.github.com/agentzh/d6c3f95c2f9ccd8294615acc78f13e6c

PR25841: c++11 dumb down iteration

Recent new code in tapsets.cxx used the "new"
   for (auto x : CONTAINER) { }
construct, which some of our older rhel6 era c++ compilers can't grok.
So for now, uglify the code.

PR25841: support context vars in functions called from process.mark probes

Extending the prior work to <sys/sdt.h> markers.  This is tricky
because the sdt derived_probes are built with a sequence of
intermediate copies and an ultimate transform to a process.statement
probe.  So the function-cloning & .mark() context-var replacement is
done early, before the synthetic process.statement builder gets a kick
at cloning/etc.  (And the latter doesn't know about sdt $$provider
etc.)

The oddest change is to deep_copy_visitor::visit_functioncall() which
used to clear the copy's referents[] array, but now we preserve (for
reasons elaborated upon in comments).  This has the potential to
impact all the other probes, but initial testing shows nothing
adverse.  No idea why we didn't do this earlier.

Nuked the unused sdt_query::convert_probe() function, not used since
deprecation of sdt-v1.  And an addendum to the message for commit
00ee19ff030f66: removed some ancient symbol-table-only
probe-resolution code machinery.  We can still probe that way, but the
code doesn't actively try to avoid pulling in debuginfo any more.

stappaths: add debuginfod commentary

Runtime: _stp_vma_match_vdso: fixed a NULL pointer dereference bug in m->path[0].

CentOS 6's kernels would generate _stp_module_N structs with NULL .path
fields (like the one with .name = "kernel"), as in

https://gist.github.com/agentzh/f95ddb650ab39d90821817015da8fe8a

A typical kernel panic error message looks like this:

https://gist.github.com/agentzh/5d8637031cbbc1bad4985b4254769cf5

testsuite: retire semok/twenty.stp

This test case is an unnecessary strain for the testsuite, because it
tries to enumerate tons of kernel probe points, but does nothing to
filter or assert correctness.  It's a stress test only of the RAM of
the test machine.

PR25841: some initial doc/test blurbs

Added a little bit of text to stap.1 and stapprobes.3 to outline the
new function $context situation.  Added one initial test case.

PR25841 for dwarf probes: permit functions to use $context constructs

Major extension to expressivity to script functions.  We now allow
them to use $context variables, as if they were written into each
probe point handler body where they are called (transitively) from.
This is accomplished by cloning such callgraphs-of-functions for
each probe, and expanding $context type operations from within
early during the probe derivation process.

This requires some gymnastics, because some symbol resolution needs to
happen -during- the derived-probe building time (when dwarf context
etc. are still available), not later when usual.  To help this, the
systemtap_session object gets a current_resolver symresolution_info
field, which represents the "current" resolver that any of the various
derived-probe builders are using currently.  This field is used in the
new function var_expanding_visitor::visit_functioncall(), to recurse
across function call boundaries.

In dwarf_cast_expanding_visitor::visit_cast_op and
dwarf_atvar_expanding_visitor::visit_atvar_op, the default "kernel"
module-name is removed as of --compatible=4.3, since the default is
inherited from the probe context itself.

This facility requires extensions from each probe point family type in
order to support.  kernel.trace() cannot soon, and process.mark()
cannot just yet.

stap -vp2: wrap function/block pretty-prints in { }

... so even one-liner functions and probes have recognizable boundaries
in a stap -vp2 dump.

uconversions.stp: worked around kernel's pointer value hashing.

PR25485: also disable -Wno-{pointer<->int}-cast for kernel modules :p

the prior patch was only for DynInst builds

Add new tapset func dump_stack()

More kmalloc -> vmalloc migrations

Almost all of the kmalloc() allocations exceeding 4KB have been
replaced by vmalloc(). This helps stap's kernel runtime work
properly on systems with serious fragmentation in physical memory
address space.

fix for 32-bit recent gcc: -Wno-{pointer<->int}-cast

Enable -Wno-int-to-pointer-cast and -Wno-pointer-to-int-cast as it
prevented compiling known-safe stap module code on 32-bit Fedora 30
systems.

python support: prep our module enumerator script for python3

stap-resolve-module-function.py includes an "import imp", which
generates a stap-unfriendly deprecation warning.  The code still
runs as of python 3.7, so simply squelching the warning for now.

kernel tracepoint support update: clk, fsi, ib_*

Add miscellaneous forward decls and extra headers for three kernel
subsystems.  On 5.5.11, this adds 198 new stap-visible tracepoints.

examples: add two more old cve security band-aids

cve-2018-6485
cve-2018-1000001

PR12609 redux: filter out duplicate probes due to partial-inining

Ever since gcc 4.7ish, partially-inlined functions can sometimes show
up as separate top-level functions named FOO.part.* in the ELF symbol
table, but identifed as ordinary function FOO in DWARF.  The latter
means that stap would probe both the partially inlined part of the
function, and the non-inlined second part, for a plain .function()
probe.  This new code suppresses the probe on the .part. one, based
on a symbol name heuristic.

Also RHBZ1169184.

RHBZ1795159: unbreak java.exp test cases

Recent changes related to synthetic-flagged probes interacted poorly
with an ancient commit 1ee0d3bab567, which thinks these probes are
in a sense negligible.  Threading a new path between those heuristics
to ensure that

       stap -l junk -E 'probe timer.s(1) { next }'

still fails, but synthetic-only probe scripts (like those triggered by
java.exp) are nevertheless accepted.

testsuite: listing_mode_sanity.exp: update for new vfs_read() signature

Modern kernels have different type parameters, so it's time relax the matching regexp.

PR25686: Fix ambiguous octal escapes in _stp_text_str

Tapset functions like user_buffer_quoted that use the _stp_text_str function
for octal escaping would produce incorrect output if a null byte was followed
by a byte that represents a printable digit in US-ASCII. The null byte would
be emitted in the shorthand \0 form, then the printable digit would be emitted
literally, resulting in (e.g.) \06 instead of \0006 for the two input bytes
"0x00 0x06".

Fix by disabling shorthand escapes for null bytes. The alternatives are to:

(a) look ahead in the buffer to see if the next byte is a digit and only
expand the \0 to \000 if it would be ambiguous; or
(b) octal-escape all printable digits

The second would be woeful for the intended function of human-readable-ish
buffer representations. The former seems potentially fragile and risky,
so I just went with simple.

tapset docs: tweak SystemTap_Tapset_Reference overload.py for newer lxml

Newer versions do not have the write(doctype=...) parameters, as
noticed on some debian build attempts with --enable-docs
--enable-refdocs.  Add stub info for a few parameters in
linux/ucontext-unwind.stp.

emptiness is fulfilling

empty

blank commit

RHBZ1810216: fix ftrace() tapset function related autoconf test

It was reported that the ftrace() tapset function stopped working at
some point - due to an autoconf-* false negative.  We failed to notice
because the tapset function was quietly mapped to a nop in this case.
Now ftrace() will #error in -p4 if autoconf doesn't detect a suitable
kernel facility.  A forked testcase buildok/logging-embedded2.stp
checks for it.

Suggested-by: Oleksandr Natalenko <onatalen@redhat.com>

Bug: proc_mem_rss() broken on older kernels lacking MM_SHMEMPAGES.

This is a regression introduced in commit de253786000.

.mailmap update

testsuite: add $return = 1 typo regression test

loc2c-runtime: fix compilation failure

I ran into the following compilation failure when I tried to change
$return in a return probe for some user-space process:

    # ./runstap.sh
    Pass 1: parsed user script and 478 library scripts using 238944virt/81096res/12424shr/68276data kb, in 790usr/230sys/1187real ms.
    Pass 2: analyzed script: 3 probes, 6 functions, 1 embed, 2 globals using 255944virt/99036res/13544shr/85276data kb, in 300usr/70sys/449real ms.
    Pass 3: translated to C into "/tmp/stapnWDsqi/stap_ea515d442eab2d1921c7105860f0337f_3673_src.c" using 255944virt/99364res/13872shr/85276data kb, in 270usr/430sys/716real ms.
    In file included from /usr/share/systemtap/runtime/linux/runtime.h:217,
      from /usr/share/systemtap/runtime/runtime.h:26,
      from /tmp/stapnWDsqi/stap_ea515d442eab2d1921c7105860f0337f_3673_src.c:27:
    /tmp/stapnWDsqi/stap_ea515d442eab2d1921c7105860f0337f_3673_src.c: In function ‘function___private___foobar_stp__dwarf_tvar_set_return_1’:
    /usr/share/systemtap/runtime/linux/loc2c-runtime.h:297:69: error: ‘regnoo’ undeclared (first use in this function); did you mean ‘reg_info’?
     #define u_store_register(regno,value) check_store_register(c->uregs,regnoo,_stp_is_compat_task()?ARRAY_SIZE(url_i386):ARRAY_SIZE(url_x86_64),value,uu_store_register)
          ^~~~~~
    /usr/share/systemtap/runtime/linux/loc2c-runtime.h:44:23: note: in definition of macro ‘check_store_register’
       if ((regs) == 0 || (regno) < 0 || (regno) > (maxregno)) {      \
    ^~~~~
    /tmp/stapnWDsqi/stap_ea515d442eab2d1921c7105860f0337f_3673_src.c:725:3: note: in expansion of macro ‘u_store_register’
       u_store_register(0, l->__tmp0);
       ^~~~~~~~~~~~~~~~
    /usr/share/systemtap/runtime/linux/loc2c-runtime.h:297:69: note: each undeclared identifier is reported only once for each function it appears in
     #define u_store_register(regno,value) check_store_register(c->uregs,regnoo,_stp_is_compat_task()?ARRAY_SIZE(url_i386):ARRAY_SIZE(url_x86_64),value,uu_store_register)
          ^~~~~~
    /usr/share/systemtap/runtime/linux/loc2c-runtime.h:44:23: note: in definition of macro ‘check_store_register’
       if ((regs) == 0 || (regno) < 0 || (regno) > (maxregno)) {      \
    ^~~~~
    /tmp/stapnWDsqi/stap_ea515d442eab2d1921c7105860f0337f_3673_src.c:725:3: note: in expansion of macro ‘u_store_register’
       u_store_register(0, l->__tmp0);
       ^~~~~~~~~~~~~~~~
    make[1]: *** [scripts/Makefile.build:312: /tmp/stapnWDsqi/stap_ea515d442eab2d1921c7105860f0337f_3673_src.o] Error 1
    make: *** [Makefile:1544: _module_/tmp/stapnWDsqi] Error 2
    WARNING: kbuild exited with status: 2
    Pass 4: compiled C into "stap_ea515d442eab2d1921c7105860f0337f_3673.ko" in 46720usr/15990sys/64098real ms.
    Pass 4: compilation failed.  [man error::pass4]

This failure is caused by a typo of the name of an argument variable
of macro u_store_register introduced at the commit
a03b455bc656216a4829dbad08e630949d944c75.

Fix vfs.open probe use of 'cred' variable

Commit f6d683666 adjusted the vfs.open probe to obtain the $cred
target variable from a field of the $file target variable on
kernels where $cred is not available.  This change missed a
second reference to the $cred target variable within the probe.

Fix the reference to the possibly-unavailable target variable
by referencing the systemtap variable just obtained.

Fixes: Commit f6d683666 ("Adjust the vfs_open to provide cred variable with 4.18 kernels")
Signed-off-by: Frank Sorenson <sorenson@redhat.com>

PR11249 etc.: tweak userspace function blacklist

Add some uretprobes blacklist entries for 32-on-64 function
__x86.get_pc_thunk.bx and its kin.  Some bug between the kernel
uretprobes implementation and the systemtap runtime causes a SEGV on
the target process if a uretprobe is hit there.  Add retblacklist.exp
to test.

stap.1 man page: mention references to error:: / warning:: pages

Reinforce the hint that systemtap printing [man error::foo] is
literally a suggestion to run % man error::foo

@var() diagnostics: generate more dwarf detail & context

For TLS-related variables like @var("errno") in glibc, some
useful diagnostic details were just dropped on the floor as
semantic_error objects were caught but not printed.  New code
tries to arrange for these to be chained instead of lost.  In
exchange, more errors would propagate to session.print_error
as chained to the target_symbol, so now the code also has to
duplicate-eliminate the chained errors.

The net result is that at verbosity 0 or 1, we appear to get only a
few specific and valuable incremental messages, which point to the
problematic dwarf.  It would be nice to simplify this stuff, perhaps
by storing context (script-source level data, dwarf pointers, dwarf
contents, etc.) as RAII style global stack of "current details".

man pages: tweak dwarf warnings, mention mismatches and debuginfod

RHBZ1788662: update to work with older (>=3.3,<3.13) Red Hat kernels

Some <3.13 kernels have rcu_is_watching() backported.
This affects RHEL7 in particular.
Handle this case using the stapconf mechanism.

RHBZ1788662: update to work with older (>=3.3,<3.3) kernels

Older kernels (<3.13) lack rcu_is_watching() and instead have rcu_is_cpu_idle().
Yet older kernels (<3.3) lack rcu_is_cpu_idle(). Workaround there is disabled,
since the message on kernel commit #9b2e4f1880 suggests that older idle loops
would not trigger this problem, and those kernels should not have tracepoints
in idle loop.

RHBZ1795196 testsuite followup

Make debuginfo-suppression env var settings temporary via spawning
/usr/bin/env to change them in the stap subprocess only.

RHBZ1795196: tolerate partial elf + missing dwarf vmlinuz for -d kernel

Previous code in dump_symbol_tables() couldn't tolerate the case where
new elfutils opened /boot/vmlinuz* as an elf file for the kernel, and
could not extract a symbol table from that (nor an absent -debuginfo).
New code instead emits a warning and moves on.  A special error code
triggers return to the dump_kallsyms() path that prior elfutils/stap
versions rely on.