gdb stub implement questions

gdb stub implement questions

[Michael Qiu]

Hi Guys,
  I'm using ucos/ii and an r3k like mips core for my project. I'm
going to add a gdb-stub on my target. But I still have some uncleared
questions, can anyone give me a hand?

1. Is there any hardware requirement for the gdb-stub running
correctly? e.g. special instructions? Currently, my core only support
"bkpt". Is it enough?

2. I'v read the gdb-stub from yamon, but it seems only work for a
bootloader. There is no multitask. The yamon shell in charge of the
context switch, but it only a ping-pang like switch. How can I support
multitask in ucos/ii?

3. In general, the gdb-stub should be implemented in a bootloader or
in OS level, or user spaces?

Best regards

Re: gdb stub implement questions

[Daniel Jacobowitz]

On Mon, Sep 01, 2008 at 12:02:38PM +0800, Michael Qiu wrote:
> Hi Guys,
>   I'm using ucos/ii and an r3k like mips core for my project. I'm
> going to add a gdb-stub on my target. But I still have some uncleared
> questions, can anyone give me a hand?
> 
> 1. Is there any hardware requirement for the gdb-stub running
> correctly? e.g. special instructions? Currently, my core only support
> "bkpt". Is it enough?

Yes, that's probably enough.

> 2. I'v read the gdb-stub from yamon, but it seems only work for a
> bootloader. There is no multitask. The yamon shell in charge of the
> context switch, but it only a ping-pang like switch. How can I support
> multitask in ucos/ii?
> 
> 3. In general, the gdb-stub should be implemented in a bootloader or
> in OS level, or user spaces?

Sorry, the answer to these are both 'it depends'.  These are more
questions about your operating system than about GDB.

You probably want to model each task as a 'thread' to gdb.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb stub implement questions

[Michael Qiu]

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?

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?

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?

Thanks in advance.

2008/9/1, Daniel Jacobowitz <drow@false.org>:
> On Mon, Sep 01, 2008 at 12:02:38PM +0800, Michael Qiu wrote:
> > Hi Guys,
> >   I'm using ucos/ii and an r3k like mips core for my project. I'm
> > going to add a gdb-stub on my target. But I still have some uncleared
> > questions, can anyone give me a hand?
> >
> > 1. Is there any hardware requirement for the gdb-stub running
> > correctly? e.g. special instructions? Currently, my core only support
> > "bkpt". Is it enough?
>
> Yes, that's probably enough.
>
> > 2. I'v read the gdb-stub from yamon, but it seems only work for a
> > bootloader. There is no multitask. The yamon shell in charge of the
> > context switch, but it only a ping-pang like switch. How can I support
> > multitask in ucos/ii?
> >
> > 3. In general, the gdb-stub should be implemented in a bootloader or
> > in OS level, or user spaces?
>
> Sorry, the answer to these are both 'it depends'.  These are more
> questions about your operating system than about GDB.
>
> You probably want to model each task as a 'thread' to gdb.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: gdb stub implement questions

[Michael Qiu]

2008/9/1, Michael Qiu <fallwind@gmail.com>:
> 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?

    It seems a stupid question. When the OS isn't running, there is no
idea of tasks and codes're running in a temp stack. It looks if I want
to debug OS, I should always doing some work in OS level.
>
> 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?
>
> 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?
>
> Thanks in advance.
>
> 2008/9/1, Daniel Jacobowitz <drow@false.org>:
> > On Mon, Sep 01, 2008 at 12:02:38PM +0800, Michael Qiu wrote:
> > > Hi Guys,
> > >   I'm using ucos/ii and an r3k like mips core for my project. I'm
> > > going to add a gdb-stub on my target. But I still have some uncleared
> > > questions, can anyone give me a hand?
> > >
> > > 1. Is there any hardware requirement for the gdb-stub running
> > > correctly? e.g. special instructions? Currently, my core only support
> > > "bkpt". Is it enough?
> >
> > Yes, that's probably enough.
> >
> > > 2. I'v read the gdb-stub from yamon, but it seems only work for a
> > > bootloader. There is no multitask. The yamon shell in charge of the
> > > context switch, but it only a ping-pang like switch. How can I support
> > > multitask in ucos/ii?
> > >
> > > 3. In general, the gdb-stub should be implemented in a bootloader or
> > > in OS level, or user spaces?
> >
> > Sorry, the answer to these are both 'it depends'.  These are more
> > questions about your operating system than about GDB.
> >
> > You probably want to model each task as a 'thread' to gdb.
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery
> >
>

Re: gdb stub implement questions

[Wenbo Yang]

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