From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18721 invoked by alias); 26 Mar 2007 21:33:58 -0000 Received: (qmail 18701 invoked by uid 22791); 26 Mar 2007 21:33:56 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Mar 2007 22:33:52 +0100 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id BE202136234; Mon, 26 Mar 2007 14:33:49 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01747-02-2; Mon, 26 Mar 2007 13:33:43 -0800 (PST) Received: from ussunex02.palmsource.com (unknown [192.168.101.10]) by mx2.palmsource.com (Postfix) with ESMTP id 1F187137382; Mon, 26 Mar 2007 14:33:41 -0700 (PDT) Received: from 192.168.92.92 ([192.168.92.92]) by ussunex02.palmsource.com ([192.168.101.10]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Mar 2007 21:33:04 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 26 Mar 2007 14:33:03 -0700 Subject: Re: Log every call and exit in embedded system From: Michael Snyder To: John Zoidberg Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 26 Mar 2007 21:33:00 -0000 Message-Id: <1174944783.24110.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 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/msg00319.txt.bz2 On Sat, 2007-03-24 at 20:05 +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. That actually depends. Don't dismiss the possibility too lightly. > I've also looked into GDB manual for tracing and logging, but didn't > found anything that can solve my problem in a direct way. I tried > backtrace but couldn't get any usefull information. Not sure what you mean by that, but you may be misunderstanding what "backtrace" does. It prints the current call stack at any given time. You would want at least some of this info if you need to construct a callgraph, but it's not sufficient. > The idea is to understand its callgraph, so it's a one time operation. > I'm not looking for profiling or statistics (of course that being able > to do this would be great). Now -- there are static tools that will construct a callgraph simply by analyzing the source code. If this isn't what you want, what is it that you need in addition to a static callgraph? Some sort of frequency counts? You say you're not looking for statistics... > ATM, my idea is to create a script that: > (1) parses objdump output to get symbols and > (2) create a GDB command file that sets a breakpoint in every symbol. > I'll then read the commands file, run the target and manually take > note of the function name and source code filename (because there are > symbol name collisions) everytime a breakpoint occurs. Not sure what you mean by "manually". GDB will print that info automatically each time a breakpoint is hit. You can just pipe the output to a file. You can attach a command script to each breakpoint to tell gdb to continue, so that you don't have to do that manually either. > Problems with this approach: > (1) unable to tell when a function returns, so it's impossible to tell > what is the level at which functions are being called. This is > especially true in assembly files (i.e., was it a JMP or was it a > RET?) Presumably your breakpoints will be at the function entry point. You won't get any events on RET. You'll only get call events, or potentially JMP events in assembly code. > (2) unable to track macros and inline code :( GDB has some mechanisms for both -- look in the manual. > (3) can GBD handle thousands of breakpoints? No problem -- but it has to set and unset them at every stop event, and that requires a message cycle between host and target. The time it takes to start and stop will increase linearly with the number of breakpoints. > (4) it's a slow manual process because when a breakpoint fires I'll > have to take note of the symbol:filename and issue a continue See above, there is no reason why that needs to be done manually. > > OFFTOPIC: how can I define string variables for GDB command files? I > tried "set" but it doesn't accept strings. What I would like to do is > this: > export SOURCE_ROOT=/path/to/source/code/with/lots/of/dirs/ > dir $SOURCE_ROOT > dir $SOURCE_ROOT/core > dir $SOURCE_ROOT/util > dir $SOURCE_ROOT/drivers > dir $SOURCE_ROOT/drivers/ethernet You may want to use some scripting system to drive this. Shell script, makefile, expect, tcl, python...