FUNCTION::PROBEFUNC(3stap)

✨ NAME ✨

function::probefunc β€” bestie, this one hands you the probe point's function name, if it's known πŸ’…


🌸 SYNOPSIS 🌸

probefunc:string()

πŸŽ€ ARGUMENTS πŸŽ€

  • None β€” nope, zero, nada, she takes no arguments, she's just like that 🫢

πŸ’– DESCRIPTION πŸ’–

Okay so picture this: this function returns the name of the function being probed, and it figures that out based on the current address. Iconic behaviour, truly.

How does she do it? She calls symname(addr) or usymname(uaddr), depending on the probe context β€” and by "probe context" we mean whether the probe is a user probe or a kernel probe. That's the whole vibe check right there. ✨


🚨 PLEASE NOTE 🚨

lowkey important, do not skip this part bestie 😭

This function's behaviour differs between SystemTap 2.0 and earlier versions. Yes, fr fr.

Prior to 2.0, probefunc obtained the function name from the probe point string as returned by pp, and used the current address as a fallback.

So basically: old behaviour = pp first, address as backup. New behaviour = address-driven. Different eras, different energy. πŸ’€

Consider using ppfunc instead. That's the glow-up recommendation, no cap. 🌈


πŸ‘‘ SEE ALSO πŸ‘‘


okay that's the whole page, you ate that πŸ“ β€” this was pulled from the SystemTap Tapset Reference, Version as of September 2026, and yes it lives in the 3stap manual because she's fancy like that πŸ’…βœ¨

πŸ“¦ where this page comes from