From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9493 invoked by alias); 18 Dec 2009 20:21:33 -0000 Received: (qmail 9484 invoked by uid 22791); 18 Dec 2009 20:21:32 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Dec 2009 20:21:26 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nBIKLFpC023241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Dec 2009 15:21:15 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nBIKLEOJ023832; Fri, 18 Dec 2009 15:21:14 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id nBIKLDTg026151; Fri, 18 Dec 2009 15:21:14 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 79169378286; Fri, 18 Dec 2009 13:21:13 -0700 (MST) From: Tom Tromey To: Stan Shebs Cc: gdb-patches Subject: Re: [PATCH] Handle LOC_COMPUTED variables in tracepoint actions References: <4B2BDC02.9010209@codesourcery.com> Reply-To: tromey@redhat.com Date: Fri, 18 Dec 2009 20:21:00 -0000 In-Reply-To: <4B2BDC02.9010209@codesourcery.com> (Stan Shebs's message of "Fri, 18 Dec 2009 11:46:10 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-12/txt/msg00268.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> The last time that anybody used tracepoints much, stabs was still Stan> the norm and Dwarf 2 the newbie, and so nobody thought much about Stan> handling variables with computed locations. Stan> This patch doesn't handle every possible computed location, that's Stan> a big project of its own (basically translating arbitrary dwarf2 Stan> bytecode sequences into equivalent agent expression bytecodes) Fun project :-). Let me suggest a feature request for this in bugzilla... Stan> Even the simplified version is a little arcane, so I'll leave it Stan> up for comments for a few days before committing. This patch looks pretty good to me. Does this handle DW_OP_call_frame_cfa? I didn't see any explicit support for it, but I could be missing something. IIUC, recent versions of gcc tend to emit this for all local variables. I also have a couple tiny nits to pick. Stan> + struct agent_expr * Stan> + gen_trace_for_var (CORE_ADDR scope, struct symbol *var) Intro comment. Stan> + static void Stan> + dwarf_expr_frame_base_1 (struct symbol *framefunc, CORE_ADDR pc, Stan> + gdb_byte **start, size_t * length); Extra space before "length". This occurs twice. Stan> + /* We don't know what to do with the frame base expression, Stan> + so we can't trace this variable; give up. */ Stan> + error (_("Cannot generate expression to collect symbol \"%s\"."), Stan> + SYMBOL_PRINT_NAME (symbol)); As a user I would appreciate it if this error told me more about what was wrong. Like, maybe it could mention that the DWARF expression is too complicated, or maybe ask me to file a bug report. Tom