Fix some KTR/CTR casts for CHERI

[nwf]

Fixes compilation failures if options KTR is kicked on. Am open to suggestions about the correct type to cast to (ptraddr_t rather than uintptr_t?).

[jrtc27]

uintptr_t with %#lx is definitely wrong, that'll give warnings on 32-bit architectures (though work because unsigned int and unsigned long have the same representation) and be completely wrong for a purecap kernel. Just leave them as u_long and add __cheri_addr or, better, cast to u_long via uintcap_t?

[arichardson]

Can we just use %lp or is that not supported? If not this seems fine to me.

[nwf]

Oh hah. Yes, that seems to work. How's this look?

[jrtc27]

Continued use of %lx and %p but not %lp is deliberate, the parameters are stored as an array of uintptr_t.

[nwf]

This is getting a little more broad... I suspect we're going to want to store the parameters as uintcap_t (or perhaps ptraddr_t) so that it's the same size between hybrid and purecap. That may change the format specifiers we use.

[jrtc27]

My feeling is that internally we should store it as uintcap_t so the native ABI sees the right thing, and if you want a hybrid/vanilla process to work with it then you'll need compat code, but AFAIK 32-bit processes don't work with 64-bit dumps. I guess in theory we could also store a tag bitmap for CHERI.