From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23055 invoked by alias); 23 Dec 2009 23:16:42 -0000 Received: (qmail 23038 invoked by uid 22791); 23 Dec 2009 23:16:41 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Dec 2009 23:16:36 +0000 Received: (qmail 6174 invoked from network); 23 Dec 2009 23:16:35 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Dec 2009 23:16:35 -0000 Message-ID: <4B32A4C2.4000806@codesourcery.com> Date: Wed, 23 Dec 2009 23:16:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tromey@redhat.com CC: Stan Shebs , gdb-patches Subject: Re: [PATCH] Handle LOC_COMPUTED variables in tracepoint actions References: <4B2BDC02.9010209@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00365.txt.bz2 Tom Tromey wrote: >>>>>> "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 don't think so - it's probably an accident waiting to happen. :-) > 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. > I tinkered with the wording a bit, but it's difficult to explain. In general the compiler is producing output that the bytecode compiler doesn't know how to handle, and there's not much the user can do about it. It's severe enough that we should give up on the tracing run, so we need it to be an error rather than a warning, but internal_error is a bit excessive, since regular debugging still works, and the debugger state hasn't been corrupted in any way. Stan