This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb stub implement questions
Michael Qiu wrote:
Here I have an proposal, will you take a look?
Background:
I'm using uscosII, it's a multitask os, and all tasks running in the
same memory space. So it's easy to get other tasks' information.
What I suppose to do is:
1. When system startup. I will put a piece of code like this:
install_bkpt_handle(); // Install the trap handler for gdb.
bkpt; // Just trigger it.
Question: Can I just put it before OS start? If I just put it after OS
has started, then only means I cannot debug the os startup process?
Yes, you can debug the os startup process. Just put the stub in
different memory space against your os.
2. Write an exception handler to handle the bkpt exception. In this
routine I should save the context of interrupt task and swith to a gdb
remote debug protocal process task.
Question: should I disable interrupt in the exception handler and the
protocal process task? Or should I disable task scheduler when enter
the protocal process task?
Maybe you made some mistake here. If you were debugging an OS, probably
the task scheduler is meaningless to you. If you were debugging an APP
on an os, it is your os's responsibility to support stub's function.
3. When user just "continue" or "step" the program, the protocal
process task should save it's context and restore the cpu with the
previous saved context for the interrupt task.
Question: How can I do it with ucos/II's API without digging into the
code? Should the protocal process task action like an normal task or
just an routine not known to OS?
Still Daniel's answer: These are more questions about your operating
system than about GDB.
Regards,
Wenbo
--
Wenbo YANG
The State Key Laboratory Of Information Security
Graduate University of CAS, 19A Yuquan Road, Beijing, China
MSN/AIM/QQ: solrex@live.com --- Homepage: http://solrex.cn