From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1962 invoked by alias); 1 Sep 2010 23:01:29 -0000 Received: (qmail 1553 invoked by uid 22791); 1 Sep 2010 23:01:28 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Sep 2010 23:01:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F167F2BAC2D; Wed, 1 Sep 2010 19:01:21 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1MArTTSZr-1t; Wed, 1 Sep 2010 19:01:21 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9CCDA2BAC04; Wed, 1 Sep 2010 19:01:21 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6353AF599F; Thu, 2 Sep 2010 00:51:35 +0200 (CEST) Date: Wed, 01 Sep 2010 23:04:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: Hui Zhu , Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [RFA/DOC] record pic Message-ID: <20100901225135.GJ2986@adacore.com> References: <8339u3ordt.fsf@gnu.org> <20100827143946.GA2986@adacore.com> <8339u0m4vu.fsf@gnu.org> <20100827155832.GB2986@adacore.com> <20100828012447.GD2986@adacore.com> <4C7E99A6.7030006@vmware.com> <20100901182754.GC2986@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100901182754.GC2986@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00071.txt.bz2 > Hui: With your permission, I wold like to take this patch over. Here is, in short, what I have found out from reverse-engineering the code. That should allow me to write some half-decent documentation for this feature. However, before you read on, and before I do so, I would like to recommend that this feature be actually backed out. More about this in the appropriate thread. ------------------------------------------------------------------------- This feature produces a graph description using the VCG syntax. Graphs essentially have two elements: nodes and edges (the edges connect one node to the next). Notations: `[source name]' means optional source name `' means mandatory source name There are 3 types of edges: - Edges that correspond to a function call (drawn in red) - Edges that correspond to a function return (drawn in blue) - All other edges (drawn in the default color, I assume black) In the VCG file, the edges are written as: edge: {[color:] sourcename: "" target_name: ""} There are two kinds of nodes. Only one kind gets used for a given graph. Which kind is used is determined by the user setting "set record pic type ". Nodes have a `title', which is displayed in the node contents by the viewers. - Nodes associated to functions [filename-if-available] - Nodes associated to source lines either: (a) : [function linkage name] or: (b) [function linkage name] [line number] (a) is used in the case when the new instruction corresponds to a different frame from the previous instruction (either a function call or a return) AND when the new instruction has a symtab (debug info) (b) is used otherwise. The `function linkage name' is provided when known. WARNING: The code only checks the symbol table, and ignores debugging info. This is a problem on platforms where the linker eliminates static functions. The line number is provided if known (symtab). This is the case where we have debugging info, but it's still in the same frame. Effect of the various user settings: - set record pic hide-nofunction If set to on, then nodes associated to instructions for which we cannot find a function in the symbol table are not included in the graph. - set record pic hide-nosource If on, filters out the nodes associated to instructions for which no debugging information is available (typically, code compiled without debugging information, or code that got stripped). - set record pic hide-sameaddr If on, nodes corresponding to the same address get merged. For "function" graphs, the merging stops as soon as the associated function returns. For line graphs, the merging is always done. The number of nodes being merged is indicated at the end of the node title as c: where is the number of times this node was found. If off, nodes are not merged. Instead of the cound, the intruction number, whetever that might be, is indicated at the end of the node title as i: where is that instruction number. -- Joel