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