Re: tprof(8) ABI

Kevin Bowling <[email protected]> Sun, 19 Apr 2026 23:10:47 -0700
Newsgroups gmane.os.netbsd.devel.userlevel,gmane.os.netbsd.devel.kernel,gmane.os.netbsd.ports.mips.devel
Message-ID <CAK7dMtCM-sGn=BHMBGfjVEkJ5xFthGFt4SRrqtZ9zE8SvqEiXA@mail.gmail.com>
On Sun, Apr 19, 2026 at 9:32=E2=80=AFPM Martin Husemann <[email protected]=
> wrote:
>
> On Sun, Apr 19, 2026 at 05:54:23PM -0700, Kevin Bowling wrote:
> > Hi Nick,
> >
> > My understanding is we are trying to capture a 64-bit PC from the
> > kernel into a structure that n32 userland reads. If we sign extend a
> > 32-bit value read from the kernel, I'm not sure if we'd have the right
> > value in every case but I don't fully grasp the sign extension.  I
> > suppose we'd need to understand some other cases like x86 user on
> > amd64 or sparc on sparc64 too, and KASLR?
>
> Why is the kernel PC relevant here? I thought this would sample the
> userland PC as observed by the kernel, and for 32bit userland processes
> this can always only be a 32bit value (on sparc and i386 zero extended,
> on mips and riscv probably sign extended).

We are instrumenting the 64-bit kernel, but we are using a 32-bit
userland utility to tell us what is going on in the 64-bit kernel.  I
think it's a binary contract, the tprof driver pumps out the hardware
events, so you'd want the 'real' PC but for this ABI break.  On 32-bit
systems it would just make the profile files a little bigger.

> Martin