From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21045 invoked by alias); 7 Aug 2002 02:21:14 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21038 invoked from network); 7 Aug 2002 02:21:14 -0000 Received: from unknown (HELO saturn.billgatliff.com) (209.251.101.200) by sources.redhat.com with SMTP; 7 Aug 2002 02:21:14 -0000 Received: by saturn.billgatliff.com (Postfix, from userid 500) id CED804E0004; Tue, 6 Aug 2002 21:21:13 -0500 (CDT) Date: Tue, 06 Aug 2002 19:21:00 -0000 From: "William A. Gatliff" To: Nicolas Moreau Cc: gdb@sources.redhat.com Subject: Re: RTOS awareness Message-ID: <20020806212113.A2149@saturn.billgatliff.com> Reply-To: bgat@billgatliff.com References: <3D510273.8727.5B50901@localhost>; <20020806203350.A1780@saturn.billgatliff.com> <3D5108FD.14161.5CE929C@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D5108FD.14161.5CE929C@localhost>; from nicolas@enttec.com on Wed, Aug 07, 2002 at 11:48:13AM +1000 X-SW-Source: 2002-08/txt/msg00043.txt.bz2 Nick: > We are not using a stub but a JTAG interface to the processor (ARM7 > core), can we still redirect the printf ? Dunno. Although it's hardly a comparison, my Abatron unit for CPU32 can. When the target takes a particular trap with the registers set a certain way, it'll snarf up the text string pointed at by one of the registers and package it up n a 'O' packet--- thereby sending it to the gdb display. Don't see any reason why it couldn't be done for JTAG in the same way, it's just a question of whether your JTAG interface vendor builds in that functionality. > How can you call a function form the GDB command line ? Assuming you have a function like this in your application: int foo (void); (gdb) print foo() will work. Other function signatures work as well, and gdb will invoke the target's malloc() if necessary to make room for reference arguments like strings. *Quite* cool and useful! b.g. > > Thanks > > Nick > > On 6 Aug 2002 at 20:33, William A. Gatliff wrote: > > Date sent: Tue, 6 Aug 2002 20:33:50 -0500 > From: "William A. Gatliff" > To: Nicolas Moreau > Copies to: gdb@sources.redhat.com > Subject: Re: RTOS awareness > Send reply to: bgat@billgatliff.com > > > Nick: > > > > > > Pardon me from providing an incomplete answer, but you may also > > consider just having some "helper functions" with your stub or > > application that provide the needed functionality via printf() > > (redirected to gdb's console, for example). You would call those > > functions from gdb's command line, rather than mucking with gdb source > > code. No gdb mods required. > > > > Just a thought. I think eCos (another RTOS) uses this technique. > > > > > > b.g. > > > > On Wed, Aug 07, 2002 at 11:20:19AM +1000, Nicolas Moreau wrote: > > > Hi > > > > > > I would like to write a UCOS II (embedded RTOS) awarness module for > > > GDB to use on our embedded system. What I want to display is the > > > data structure associated with each task, the display has to be in a > > > user friendly format (no raw memory dump) Where can I start ? How > > > can I extend the fucntionality of UCOS ? What source files should I > > > be looking at ? > > > > > > Thanks > > > > > > Nick > > > > > > > -- > > Bill Gatliff > > bgat@billgatliff.com > > > > -- Bill Gatliff bgat@billgatliff.com