On Tue, 18 Apr 2000, Darren Reed wrote:

> In some email I received from Simon Burge, sie wrote:

> >  2) Need a way to get the address of the ps_strings struct for a given
> >     process - this can vary per process on a machine running both 32 and
> >     64 bit processes.
> > 
> >     Possible solutions: add
> >         
> >         sysctl(CTL_KERN, KERN_PROC_PSADDR, pid, &va);
> > 
> >     or keep address of ps_strings in struct proc and pass back inside
> >     struct kinfo_proc2.
> 
> This is bad.  As much as others may detest it, I'd go for putting this
> information in a static sized buffer.  If people do "ps axwww" or "ps e"
> then it should fall back, as required, to a method which supports the
> return of architecture dependant sized structures.
> 
> Another option is to create something like this:
> 
> struct foo {
>         union {
>                 uint64_t        u64;
>                 uint32_t        u32;
>         } fu;
> }
> 
> and conditionally fill the appropriate part in the kernel.

????  

I have a 32-bit `ps' binary.  How does it know whether to access the
`.u32' or `.u64' member?  If it choses the wrong one it gets garbage.

> For 32bit binaries running on a 64bit system, it may also be that the
> pointer once squeezed into 32bits no longer makes sense - for example
> when user applications have an address space > 4GB.  So again, if you
> really want to be 32bit compatible, don't return any pointer information.

Absolutely.  That's why pointers are being passed around in 64-bit fields.

The C standards have not addressed the issue where I have 32-bit pointers
and you have 64-bit pointers, and I hand you a pointer to an object and
expect you to be able to access it.  Or visa-versa.

The size of the pointer is not really important.  What is important is
that the 32-bit application recieve a structure with all the data in
correct locations.  It just so happens that `ps' has always printed out
pointer fields from the proc structure for debugging purposes.  If you
don't provide them you break backwards compatibility (and possibly POSIX
compliance.  Any POSIX weenies in the audience?)

The other option is to provide another machanism to allow structure
translation before the copyout() is performed.  But while the former
option is wasteful in 32-bit architectures, this one is guaranteed to
trash the pointers in 32-bit emulation.

Eduardo Horvath