From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17568 invoked by alias); 18 May 2004 14:57:10 -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 17549 invoked from network); 18 May 2004 14:57:06 -0000 Received: from unknown (HELO reserv5.univ-lille1.fr) (193.49.225.19) by sourceware.org with SMTP; 18 May 2004 14:57:06 -0000 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv5.univ-lille1.fr (8.12.11/jtpda-5.3.1) with ESMTP id i4IEv2HK009535 for ; Tue, 18 May 2004 16:57:02 +0200 Received: from lifl.fr (helios.lifl.fr [134.206.10.253]) by malonne.lifl.fr with ESMTP id i4IEv4s21728 for ; Tue, 18 May 2004 16:57:04 +0200 (MEST) Message-ID: <40AA23FD.6040103@lifl.fr> Date: Tue, 18 May 2004 14:57:00 -0000 From: Alexandre Courbot User-Agent: Mozilla Thunderbird 0.5 (X11/20040229) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: GDB as a program analyzer - some thoughts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-SW-Source: 2004-05/txt/msg00121.txt.bz2 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. 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 - 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 Would these features be desirable? Would they not? Alex. -- Alexandre Courbot - PhD student RD2P/LIFL http://www.lifl.fr/~courbot