Accessing address space of a process through kld!!

[Andrey Simonenko]

On Fri, Mar 03, 2006 at 09:26:35PM +0530, Tanmay wrote:
> On Tue, Feb 28, 2006 at 01:33:47PM -0500,
> John Baldwin wrote:
> >you can use the proc_rwmem() function (it takes a uio >and a struct proc)
> >to do the actual I/O portion.  You can see example use in >the ptrace()
> >syscall.
> 
> Thanks.The memory of the process could be read using the proc_rwmem function
> .
>     How can i access the stack segment of a process ? I tried knowing more
> about the stack allocation by running a small (user-level) program and
> observing its addresses using GDB.Then I printed the max VA address and
> stack size for that process from my KLD using  p->p_vmspace->vm_maxsaddr and
> p->p_vmspace->vm_ssize respectively.But i could not infer anything
> useful.Can you shed some light on this ? At what address does the stack
> segment start ? where can we get this address from for a running process ?
> 

In struct sysentvec{} there is sv_usrstack field, which gives the top
address for stack.  Each process has pointer to its own sysentvec in
p_sysent.  It is possible to get this value by reading kern.usrstack
value, kern.usrstack is not a global system value, it is value of
current process's p_sysent->sv_usrstack.  sv_usrstack is usually MD
macro variable USRSTACK.

Memory for stack is allocated by portions and grows down or up, depending
on architecture.  Each portion is sgrowsiz size.  As the result for stack
several vm_map_entries are allocated.  Even if some program will not use
already allocated stack there is not any way for the system to release
memory used by previously allocated stack.  I mean normal stack usage,
not alternative stack provided by an application.

I do not know your task, but if you need something in stack, then you
really need all vm_map_entries of stack, since an application can have
several threads (type of multithreading does not metter) and each thread
has own portion of stack.

This is the example of stack of my test program run on i386, where
stack grows to lower addresses:

0xbfb80000 0xbfba0000 32 0 0xc4097210 rwx 1 0 0x2180 NCOW NNC default -
0xbfba0000 0xbfbc0000 32 0 0xc3e32420 rwx 1 0 0x2180 NCOW NNC default -
0xbfbc0000 0xbfbe0000 32 0 0xc4201000 rwx 1 0 0x2180 NCOW NNC default -
0xbfbe0000 0xbfc00000 32 0 0xc3e3918c rwx 1 0 0x2180 NCOW NNC default -

The size of each vm_map_entry is 128k, the same value as SGROWSIZ.