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