It doesn't look like this test should even trigger the liveness analyzer.  But it'd be good to make it robust with whatever bothered it here.

There is a $return=-1 in probe kernel.function("*do_fork").return which could trigger the analysis as it is a write.  However, the question is what is causing:

stap: /builddir/build/BUILD/dyninst-11.0.0/dyninst-11.0.0/dataflowAPI/src/liveness.C:418: bool LivenessAnalyzer::query(Dyninst::ParseAPI::Location, LivenessAnalyzer::Type, const Dyninst::MachRegister&, bool&): Assertion `index >= 0' failed.

It looks like there is something going wrong with the register name machReg being passed into:

bool LivenessAnalyzer::query(Location loc, Type type, const MachRegister& machReg, bool &live){
	bitArray liveRegs;
	if (query(loc, type, liveRegs)){
        int index = getIndex(machReg);
        assert(index >= 0);
		live = liveRegs[index];
		return true;
	}
	return false;

}

One possible way things could be going wrong is if register width is gotten wrong and the wrong register name, 32-bit name rather than 64-bit, is passed in.  The analysis code is really picky about the register names being used as there are some differences in the ABIs between 32-bit and 64-bit variants of architectures (particularly x86).

I was thinking that some odd dwarf register number is being passed in, but if that was the case the analysis wouldn't run and the assert wouldn't happen.

The register dyninst register selected for the liveness analysis looks sane, ppc64::r3.  The dyninst code is getting a bit confused whether this is 32-bit or 64-bit code being analyzed. It does 64-bit liveness analysis, but tries to use mappings for 32-bit register names (https://github.com/dyninst/dyninst/issues/1165).  That results in the ppc64::r3 not being found because the index only has ppc32::rn entries and the assert failing.

Have a proposed systemtap patch on following branch that works around the issue with the ppc64/ppc32 register naming and avoids the assert fail:

https://sourceware.org/git/?p=systemtap.git;a=shortlog;h=refs/heads/wcohen/rhbz2028840

With the patch:

# stap -vp4 -g fork.stp
Pass 1: parsed user script and 509 library scripts using 143488virt/108224res/21632shr/84096data kb, in 290usr/30sys/308real ms.
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
 can't find 0x28080310
Pass 2: analyzed script: 7 probes, 10 functions, 0 embeds, 2 globals using 3932992virt/2243072res/207744shr/3630080data kb, in 94210usr/970sys/17228real ms.
Pass 3: translated to C into "/tmp/stapY0bigs/stap_6f843142437f76749d5af4925919c4d7_5836_src.c" using 3932992virt/2243328res/208000shr/3630080data kb, in 30usr/80sys/115real ms.
/root/.systemtap/cache/6f/stap_6f843142437f76749d5af4925919c4d7_5836.ko
Pass 4: compiled C into "stap_6f843142437f76749d5af4925919c4d7_5836.ko" in 44200usr/1950sys/9341real ms.


There looks to be dyninst an issue with ppc64 handling related to this:

https://github.com/dyninst/dyninst/issues/1142

Verified with systemtap-4.7-1.el8, dyninst-12.1.0-1.el8, on top of kernel-4.18.0-387.el8.  The script from Comment#0 now compiles (-vp2) without issues on all the arches.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (systemtap bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7538