On Mon, 17 Apr 2000, Simon Burge wrote:
> Eduardo Horvath wrote:
>
> > On Sat, 15 Apr 2000 erh@nimenees.com wrote:
> >
> > If I recall correctly, the original source for this discussion was my
> > mentioning that sysctl() and kernel grovelling does not work well for
> > binaries under 32-bit emulation.
>
> I thought the original motivation (and has been my main motivation) was
> fixing ps's "proc size mismatch" errors, but 32 bit emulation is another
> canditate as well. Indeed, I don't think I'd seen a reference until
> you sent one just after I sent my message about an implementation being
> available. Crossed wires or whatever...
Maybe it was started on a different list...
> > You should either get rid of all these pointers and convert them to a
> > u_int64_t so the structure does not change, or provide some mechanism to
> > repack te structure before the copyout() so this entire mess does not need
> > to be reimplemented inside COMPAT_NETBSD32 code.
>
> Ok, I've just about changed it so that _all_ fields are {u_,}intXX_t's,
> except for the char[] fields. One remaining hassle is sigset_t which is
> defined as a structure of 4 u_int32_t's. Instead of
>
> sigset_t p_siglist;
>
> I could have
>
> u_int32_t p_siglist[SIGSET_LEN];
>
> but that seems sorta ugly.
That's a fixed sized structure in a MI header file. It should be O.K.
> To deal with pointers, I've changed all pointers in kinfo_proc2 to
> u_int64_t's, and got in fill_kproc2():
That's good.
> #define PTRTOINT64(foo) ((u_int64_t)(long)(foo))
That's not. This is probably architecture dependent. For sparc64 you
would want to use ((u_int64_t)(unsigned long)(foo)) since the 32-bit
address space is all in the low 4GB. This is a H/W thing. Other
architectures may use sign extension and the bottom and top 2GB.
For 32-bit architectures this is a noop, but for 64-bit machines it's
probably good to allow this to be overridden by an MD header file.
> One more thing - I guess I have to worry about structure packing,
> especially for the compat32 case, right? If so, I'll arrange for
> everything to be aligned at 8 bytes then.
>
> Will these changes address all of your compat32 concerns? I don't have
> anything to test this against - I imagine sparc64 with sparc userland is
> the only user of this at the moment?
Yes, I think that should be sufficient.
Eduardo Horvath