how does linux restores a thread's stack pointer, program counter and return address.

* how does linux restores a thread's stack pointer, program counter and return address.
@ 2011-10-04  4:20 Smital Desai
  2011-10-04 12:50 ` Chauhan, Himanshu
  2011-10-04 18:33 ` Dave Hylands
  0 siblings, 2 replies; 3+ messages in thread
From: Smital Desai @ 2011-10-04  4:20 UTC (permalink / raw)
  To: kernelnewbies

Hi.
I am using linux 2.6.39 and MIPS core.
I am keen to find out how does linux restores a thread's stack pointer, program counter and return address.

I have created a binary which spawns four threads. with a ps -eaL , then I kill one of the thread with kill -11 <thread_id>. In the kernel 'do_coredump' handler i can easily find out the stack pointer of the current crashed thread by reading the struct pt_regs->reg29. My concern is to find out the stack pointers of rest of the 3 threads that did not crash. I did it this way:

1. read the reg29 variable of struct thread_struct for each task (By traversing the list of task with list_for_each)
2. Dump the values at address stored in reg29.
3. Look out manually to locate the Stack pointer offset. Tried this by crashing all the threads and found that the stackpointer comes at a fixed offset and assumed that stack pointer to be correct and I went ahead.

so you can say that my Stack pointer is stored at => reg29 + offset;

My question now is how to find this value of 'offset' dynamically. How does the kernel keeps a track of any thread's stack pointer while restoring the context. Since my observation was that the reg29 field of struct thread_struct at a glance seems to be a stack pointer. but it is not. it is just an address where at some offset we can find our stack pointer stored.

Thanks
Smital Desai

________________________________
The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. L&T Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail"

______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111004/544e5aaf/attachment-0001.html 

^ permalink raw reply	[flat|nested] 3+ messages in thread