From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10415 invoked by alias); 18 Mar 2010 18:20:01 -0000 Received: (qmail 10395 invoked by uid 22791); 18 Mar 2010 18:20:00 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 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; Thu, 18 Mar 2010 18:19:54 +0000 Received: (qmail 8344 invoked from network); 18 Mar 2010 18:19:53 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Mar 2010 18:19:53 -0000 Message-ID: <4BA26EC3.2020307@codesourcery.com> Date: Thu, 18 Mar 2010 18:20:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: tromey@redhat.com CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: [PATCH] More C++ static fields for tracepoints References: <4BA15504.9020707@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: 2010-03/txt/msg00677.txt.bz2 Tom Tromey wrote: >>>>>> "Stan" == Stan Shebs writes: >>>>>> > > Stan> This patch solves a couple intertwined problems relating to > Stan> tracepoint collection of C++ classes with static fields. First, > Stan> it adds recognition of variables (including static fields) whose > Stan> location expressions indicate that they have been optimized out. > > As ax-gdb grows I am starting to wonder whether we could unify it with > eval.c somehow. > "It would be nice." There was some discussion in that general vein back around 2002-3, connected with dwarf2 computed locations; http://sourceware.org/ml/gdb-patches/2002-07/msg00124.html alludes to the idea for example. Certainly it becomes compelling beyond tracepoints if you wanted to do something like breakpoint conditions on the target; as an additional teaser, one of the things we did for Ericsson was to JIT-style compile the agent bytecodes to x86 native, which gives condition-testing times close to what one would get for conditional code hand-written into the sources. The downside is that GDB's evaluator frequently makes on-the-spot decisions about what to do next based on data pulled from the target, so abstracting all that out is going to be rather painful. > Stan> Second, to collect an instance of a class with static fields, we > Stan> need to issue more bytecodes, since static fields are stored at > Stan> their own addresses, separately from the instance. > > A static field may itself be of a type with static fields. That doesn't > seem to be handled in this code... should it be? And if so, be careful > about the case where a class refers to itself recursively via static > fields; we still have some printing bugs in this area :( > Hmm, I'll check it out - I wonder it's flattened out, static field iteration doesn't seem to recurse as one might expect. Stan