From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18211 invoked by alias); 27 Mar 2007 09:56:44 -0000 Received: (qmail 18199 invoked by uid 22791); 27 Mar 2007 09:56:42 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Mar 2007 10:56:39 +0100 Received: by py-out-1112.google.com with SMTP id p76so1129778pyb for ; Tue, 27 Mar 2007 02:56:37 -0700 (PDT) Received: by 10.35.33.15 with SMTP id l15mr13973384pyj.1174989397256; Tue, 27 Mar 2007 02:56:37 -0700 (PDT) Received: by 10.35.73.12 with HTTP; Tue, 27 Mar 2007 02:56:37 -0700 (PDT) Message-ID: Date: Tue, 27 Mar 2007 09:56:00 -0000 From: "John Zoidberg" To: "Michael Snyder" , gdb@sourceware.org Subject: Re: Log every call and exit in embedded system In-Reply-To: <1174944783.24110.43.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1174944783.24110.43.camel@localhost.localdomain> 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/msg00322.txt.bz2 On 3/26/07, Michael Snyder wrote: > 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. What I mean is that due to the nesting level of calls I'm unable to get a useful call stack. I can see the call stack at a certain level, but I can't see what happened in deeper levels (and a lot happens there). > > 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? I suspect those tools won't support assembly modules and will have problems with branching (i.e. I'll have to debug to know where execution flows). But if those tools are capable of handling hundreds of files across multiple directories they will still be useful. Since I've not tested any, which ones would you recommend? > 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. Using "set logging" > 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. Using "commands" > > 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. I've re-checked GDB's behavior for assembly and it (1) breaks on the first instruction of an assembly symbol (on the jmp scenario) and (2) I can know if it was a call by checking the backtrace. > > (2) unable to track macros and inline code :( > > GDB has some mechanisms for both -- look in the manual. I've checked the manual, made a simple test and confirmed what I suspected: I'm unable to set breakpoints in macros/inline. > > (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... > Thanks for your help!