On Tue, 2 Jan 2001, Simon Burge wrote:

> > It seems that libkvm has cause to want to know the values of USRSTACK,
> > VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS.  On some MACHINE_ARCHs, these
> > aren't constant, so libkvm has to work them out at runtime.  At the
> > moment, it gets uses (__ps_strings + 1) for USRSTACK and
> > VM_MAXUSER_ADDRESS, and 0 for VM_MIN_ADDRESS.  This won't work, though,
> > for a libkvm to run on both NetBSD/arm26 and NetBSD/arm32, since they
> > define VM_MIN_ADDRESS as 0x8000 and 0x1000 respectively, since the bottom
> > logical page on each system is reserved for the CPU exception vectors.
[...]
> It appears that the only place min_uva is used is to test if the address
> of the argv/envp strings is too low.  Given that this typically only
> happens when using ps on a crash dump (because that code path isn't used
> when running ps on a live kernel) and sysctl queries the current running
> kernel this means that you may not be able to run ps on a crash dump
> created on an arm26 system on an arm32 system, in the unlikely event
> that the address of the ps strings is in the first however-many kB of
> the text of a process...

Erm, if I were to follow m68k and so on, you wouldn't be able to move
crash dumps between systems anyway, since VM_MAXUSER_ADDRESS and USRSTACK
would be derived from the host system.

> Perhaps just better to set min_uva to either the lower of the two
> possible values, or even just set it to 0?

It's possible, though this would depend on its being clear that it's safe
for it to be slightly wrong.  Assuming that libkvm only ever reads data, I
think it should be OK for it to accidentally wander over zero page --
there shouldn't be anything secret there on arm26 at least.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>