proc_t for the active process
nccc
I have some trouble with the very internals of Solaris on UltraSPARC
III. The problem is that I need access to the proc_t struct of the
process whose thread is executing on a processor. Can proc_t for the
running thread/process or a pointer to it be found somewhere in the
process address space?
Thanks,
nccc
Casper H.S. Dik
No, proc_t's only exist inside the kernel. What do you need from
the proc_t?
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
nccc
I need the pid and the path to the executable file on the disk. Please
note that I cannot execute code on the machine, because it is running
under a simulator (simics). I have to retrieve this information by
merely looking into the process address space.
nccc
address space, where exactly can I find it in the kernel memory? Is
there a fixed position for the proc_t of the active process or for a
pointer to it?
Thanks
Casper H.S. Dik
>I need the pid and the path to the executable file on the disk. Please
>note that I cannot execute code on the machine, because it is running
>under a simulator (simics). I have to retrieve this information by
>merely looking into the process address space.
It is possible only from kernel address space. Is the simulator
stopped when you look at the kernel?
Casper H.S. Dik
The CPU structure has a "thread" field and that is a thread from
the current process.
E.g., in mdb:
> ::cpuinfo
ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC
0 300014b4000 1b 0 0 49 no no t-0 300020fcae0 xterm
1 0000180c000 1b 0 0 59 no no t-0 300043a27c0 mdb
> 0000180c000::print "cpu_t" cpu_thread[0].t_procp[0].p_user.u_comm
cpu_thread[0].t_procp[0].p_user.u_comm = [ "mdb" ]
nccc
Ok, that's very fine.. Precisely what I need, thank you. But will I
always find the first cpu_t structure in address 0x180c000 in kernel
memory?
The simulator breaks at every processor mode change, i.e. from user to
supervisor mode and vice versa for any processor. Before it resumes, I
have to decide which process owns the thread that is scheduled to run..
Casper H.S. Dik
>Ok, that's very fine.. Precisely what I need, thank you. But will I
>always find the first cpu_t structure in address 0x180c000 in kernel
>memory?
No, it's all dynamic ....
>The simulator breaks at every processor mode change, i.e. from user to
>supervisor mode and vice versa for any processor. Before it resumes, I
>have to decide which process owns the thread that is scheduled to run..
Ah, right.
nccc
> No, it's all dynamic ....
>
And which struct specifies the location of the first cpu_t struct? All
this thing must have its roots in a known place, right? Maybe I reach
the undisclosed details of Solaris?...
Casper H.S. Dik
Well, they're compiled in the kernel and so the kernel can find the
particular symbol after it was loaded. The first cpu is
"cpus" and the pointers to all cpus are in the array "cpu".
nccc
This has been helpful. Thanks alot.
nccc
nccc
The reason is that, although I read the 'cpu_thread[0].t_procp
[0].p_user.u_comm' string beginning from the cpu_t struct, the string
that it contains is not the right one. And I know, because when the
cpu is executing instructions of my application, the string reads
"sched" i.e. the scheduler. It seems that this cpu_t struct does not
reflect what is actually executing on the cpu. What is going on??
nccc
Casper H.S. Dik
I can only mean that one of the kernel server threads is running on
the CPU.