Eduardo Horvath wrote:

> [[ Address of USRSTACK on sparc64 ]]
> 
> Ignore the current implementation; I don't know what I'm doing 8^).
> 
> I believe that is a correct description of the current code.  It was done
> that way so the 64-bit PS can find the PS_STRINGS.  Whether that's the
> correct implementation or the 32-bit emulation PS_STRINGS should use
> 32-bit pointers is a moot point.  You have incompatibility one way or
> another.
> 
> On the USRSTACK issue:  the 64-bit stack base will be moved up into 64-bit
> space eventually.  (I am undecided whether to move kernel up to
> 0xffffffff00000000 or leave the kernel where it is and make the user and
> kernel address spaces disjoint.  Do any other ports have disjoint kernel
> and user address spaces?)

The current libkvm implementation has a global idea of what USRSTACK is,
which obviously isn't going to be good enough under compat32.  Perhaps
the best way is to keep the address of each processes ps_strings in
the proc structure, and return either the address of ps_strings or the
compenents themselves as u_int64_t's inside kinfo_proc2.

I've already got a VM_PROC_VA sysctl (changed from my original idea of
using KERN_PROC_VA) that takes a u_int64_t as the va, so a 32bit emul ps
should be able to get the address of a 64 process's ps_strings and plug
that straight into the sysctl without even knowing that it's dealing
with large VAs (modulo pointer sizes - see below).

I don't think I like the idea of the kernel doing all the argv grovelling
for the user - I think we could get into situtions where the info we
want isn't in core, and it's better letting the userland process wait
for the info.  Correct?

And in a separate message from Eduardo:

> > So for the 32 bit emul case, you'd need to know the possibility that
> > you might be running under emulation, which isn't really possible (eg,
> > mips ps today, with mips64 maybe occuring one day).  But if we stored
> > the kernel's idea of the pointer size and looking at P_32 if the pointer
> > size is 8 bytes then we should be able to cover all possibilities...
> > 
> > sysctl HW_KERNPTRSIZE ?

I've also got a HW_KERNEL_BITS sysctl and KERNEL_BITS sysconf() (based
on the HP/UX sysconf KERNEL_BITS).

> The P_32 flag wasn't really designed for use by the program running under
> 32-bit emulation.  It was designed to allow the kernel to detect that a
> data structure needs to be converted before copyout.
> 
> As you said, if it's a 32-bit binary then either it needs to take into
> account that it may be running under a 64-bit kernel and handle things
> appropriately, or that needs to be hiddend from the program through a
> combination of kernel emulation routines and libkvm wrappers.

If a process has sizeof(void *) == 4 and sysconf(_SC_KERNEL_BITS) == 64
then it must be running under emulation.  It can then use P_32 to tell
if any given process needs pointer conversion when handling the argv
stuff.  Given games with structure packing, it may be easier to return
the individual components of ps_strings rather than let userland make a
guess - it may be possible to have a 64 bit processor that's happy to
have 4 byte alignment in structures.  And yes, all the userland stuff
should be hidden in the bowels of libkvm.


Given the above, can you see any other reasons what a 32bit emul ps
wouldn't work?  Actually, what is the current status of the emul/native
combos and what works/doesn't work with the kvm stuff?  It'd be nice to
have a spare ultrasparc lying around in my office to play around with
this... :-)

Simon.