From: "Michael Qiu" <fallwind@gmail.com>
To: "Michael Qiu" <fallwind@gmail.com>, gdb@sourceware.org
Subject: Re: gdb stub implement questions
Date: Mon, 01 Sep 2008 06:32:00 -0000 [thread overview]
Message-ID: <f74f98340808312331u30ad2edcicf39af9f3a70fa25@mail.gmail.com> (raw)
In-Reply-To: <f74f98340808312308w511d8b4em7107c2af3d546c04@mail.gmail.com>
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
> >
>
next prev parent reply other threads:[~2008-09-01 6:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-01 4:03 Michael Qiu
2008-09-01 4:11 ` Daniel Jacobowitz
2008-09-01 6:09 ` Michael Qiu
2008-09-01 6:32 ` Michael Qiu [this message]
2008-09-01 8:22 ` Wenbo Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f74f98340808312331u30ad2edcicf39af9f3a70fa25@mail.gmail.com \
--to=fallwind@gmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox