Re: tprof(8) ABI

[Kevin Bowling <kevin.bowling%kev009.com@localhost>]

On Sun, Apr 19, 2026 at 11:35 PM Kevin Bowling <kevin.bowling%kev009.com@localhost> wrote:
>
> On Sun, Apr 19, 2026 at 11:16 PM Martin Husemann <martin%duskware.de@localhost> wrote:
> >
> > On Sun, Apr 19, 2026 at 11:10:47PM -0700, Kevin Bowling wrote:
> > > 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.
> >
> > Ok, for that case we can build the userland tool as 64bit (I think
> > we do that for a few tools already). N32 userland is special as we don't
> > have to expect a 32bit kernel (different to e.g. sparc userland where both
> > could happen).
>
> If there is a clean way to do that it would be a good fix as well.
> What set would it end up in, base64?  Would just want to make sure
> PATH works correctly or some way to avoid a user accidentially trying
> to use the 32-bit one as it will segfault with the current intptr_t.

Specific to my PATH concern I suppose /usr/sbin/tprof could also just
be a wrapper shell script to check for the kernel bits and choose the
right binary at launch, or tell the user they need to install base64
or whatever if it doesn't exist.

> >
> > But from this PoV your suggested change makes sense to me.
>
> I don't know how to do the alternative so whatever is most acceptable.
>
> >
> > Martin