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?
Using uint64_t in the structure definition should make it ABI compatible for any arch userland to read the full 64-bit address. On Sun, Apr 19, 2026 at 8:38 AM Nick Hudson <[email protected]> wrote: > > On 15/04/2026 05:09, Kevin Bowling wrote: > > I implemented a tprof driver for mips octeon, but the port typically > > runs an n32 userland. This can be worked around by compiling an LP64 > > tprof(8), but I am not sure how that would work with the package sets. > > Since it is a developer tool, I propose intentionally breaking the ABI > > like the following patch. I think it would improve other 32 on 64 > > situations at the cost of an ABI break, but it is a developer tool in > > /usr/sbin so maybe this is the most pragmatic solution? > > --- a/sys/dev/tprof/tprof_types.h > > +++ b/sys/dev/tprof/tprof_types.h > > @@ -50,7 +50,8 @@ typedef struct { > > uint32_t s_flags; /* flags and counterID */ > > #define TPROF_SAMPLE_INKERNEL 0x00000001 /* s_pc is in kernel address > > space */ > > #define TPROF_SAMPLE_COUNTER_MASK 0xff000000 /* > > 0..(TPROF_MAXCOUNTERS-1) */ > > - uintptr_t s_pc; /* program counter */ > > + uint64_t s_pc; /* program counter; uint64_t for ABI compat > > + * with 64-bit kernels and n32/ILP32 > > userland */ > > } tprof_sample_t; > > typedef struct tprof_param { > > I have mostly completely forgotten MIPS ABIs, but shouldn't the PC just be > sign extended? > >
