From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22605 invoked by alias); 24 Mar 2007 22:20:48 -0000 Received: (qmail 22597 invoked by uid 22791); 24 Mar 2007 22:20:48 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Mar 2007 22:20:45 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 01F184B267; Sat, 24 Mar 2007 17:20:44 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id CA1384B262; Sat, 24 Mar 2007 17:20:43 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HVEbL-0005S1-DF; Sat, 24 Mar 2007 18:20:43 -0400 Date: Sat, 24 Mar 2007 22:20:00 -0000 From: Daniel Jacobowitz To: John Zoidberg Cc: gdb@sourceware.org Subject: Re: Log every call and exit in embedded system Message-ID: <20070324222043.GA20939@caradoc.them.org> Mail-Followup-To: John Zoidberg , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14+cvs20070313 (2007-03-13) 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: 2007-03/txt/msg00299.txt.bz2 On Sat, Mar 24, 2007 at 08:05:11PM +0000, John Zoidberg wrote: > Hi, > I am studying a FOSS embedded OS and would like to understand its > callgraph (especially assembly calls during OS initialization). > Since this is an embedded OS it means I have no access to profiling or > coverage features from GCC. Actually, it doesn't mean that at all. It means you have to go to a little more work to recover the profile data, though. GDB won't be able to help you much with this; a simulator or hardware debug interface may be able to do much better. > (3) can GBD handle thousands of breakpoints? Not really. It will get very slow. > Is this the only way? Can anyone give me any suggestions or hints? If you're not too interested in recursive calls, and you're not talking about too large an instruction trace, you could record the output of stepi and then analyze it looking for jumps and calls. It may be simpler if the data collection time is small enough for your needs. > OFFTOPIC: how can I define string variables for GDB command files? You can't. This is one of the reasons I've been talking about Python integration; it's not a small problem to solve, because of the way we define our variables. -- Daniel Jacobowitz CodeSourcery