This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb stub implement questions


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
> >
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]