From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32034 invoked by alias); 1 Sep 2008 06:32:25 -0000 Received: (qmail 32025 invoked by uid 22791); 1 Sep 2008 06:32:24 -0000 X-Spam-Check-By: sourceware.org Received: from wr-out-0506.google.com (HELO wr-out-0506.google.com) (64.233.184.228) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 Sep 2008 06:31:34 +0000 Received: by wr-out-0506.google.com with SMTP id c55so1885017wra.0 for ; Sun, 31 Aug 2008 23:31:32 -0700 (PDT) Received: by 10.90.102.15 with SMTP id z15mr7313303agb.51.1220250691904; Sun, 31 Aug 2008 23:31:31 -0700 (PDT) Received: by 10.90.31.7 with HTTP; Sun, 31 Aug 2008 23:31:31 -0700 (PDT) Message-ID: Date: Mon, 01 Sep 2008 06:32:00 -0000 From: "Michael Qiu" To: "Michael Qiu" , gdb@sourceware.org Subject: Re: gdb stub implement questions In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080901041050.GA7137@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00003.txt.bz2 2008/9/1, 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? 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 : > > 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 > > >