From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16503 invoked by alias); 18 May 2004 15:49:30 -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 16475 invoked from network); 18 May 2004 15:49:28 -0000 Received: from unknown (HELO calvin.codito.co.in) (203.199.140.162) by sourceware.org with SMTP; 18 May 2004 15:49:28 -0000 Received: from codito.com (ramana.codito.co.in [192.168.100.52]) by calvin.codito.co.in (8.12.10/8.12.10) with ESMTP id i4IFmsaH023617; Tue, 18 May 2004 21:18:58 +0530 Message-ID: <40AA2F5B.60708@codito.com> Date: Tue, 18 May 2004 15:49:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 MIME-Version: 1.0 To: Alexandre Courbot CC: gdb@sources.redhat.com Subject: Re: GDB as a program analyzer - some thoughts References: <40AA23FD.6040103@lifl.fr> In-Reply-To: <40AA23FD.6040103@lifl.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00123.txt.bz2 Hi Alexandre, > This post deals about using GDB for non-debugging purposes, I hope > it's not offtopic. I'm also hoping to find some people interested in > the same matters than I to discuss about how GDB could be improved for > analysis purposes. > > My few posts here have been basically about it. GDB is great to > extract datas out of a program and output them to a file. It's very > different to gprof - for instance, it's useful to graphically measure > the efficiency of one memory manager against another, by placing > breakpoints at memory allocation functions and recording the amount of > memory used there. The recorded datas can then proove that, with some > strategy, we saved a few garbage collections and therefore gained speed. > > This is of course nothing you can't do with printfs enclosed inside > #ifdef DEBUGs, but the advantage is that GDB allows you to do it in a > non-intrusive and much more flexible way. Well non-intrusive / rather less intrusive :-) ? There is still the overhead of a ptrace call in case of native debugging. in such cases ? Flexible yes . > I'm surprised that I haven't found a solutions dedicated to that - and > so far, gdb is by far the best solution I've found. Writing a gdb > script + the corresponding gnuplot script results in easy to get > graphes of whatever you want in your program. > > If people are interested in it, I can post some of the scripts I'm > using with their result. I can also write a tutorial page on that topic. > > I have some non-elegant bits in my scripts however. They mainly > concern breakpoints. Since the breakpoints are set into gdb scripts, > it's better if they reference symbols like function names instead of > file:line_number pairs. The line of the breakpoint might move in > future code modifications, and the gdb script won't be updated > accordingly. Unfortunately, breaking at the very beginning of the > function you are interested doesn't give you the data that has been > computed inside. > > So, I wonder if some breakpoint settings would be implementable with > gdb (or if they can already be expressed and I missed them): > - Setting a breakpoint at the returning of a function Could be done by maybe adding a pre-finish command to gdb ? Though ofcourse in modern toolchains since the size of a function is present a hack might be to write a script using using objdump / awk to generate a gdb script per function to put breakpoints at all possible return instructions ? There does not seem to be a pre-finish function. finish runs through the current activation record and returns .What you seem to want is for gdb to stop just before the function returns so that the data can be collected. > - Setting a breakpoint at some fixed point of a function (for > instance, a C label) > - Any other breakpoint setting that is not line-number based and would > support source modification In continuation with my fancy for awk , grep and objdump maybe generate your script with respect to the functions that you are interested in ? objdump -x executable; grep for the symbol, get the address and then generate the script with the correct address. Ofcourse might sound like overkill for something so simple ? > cheers Ramana