From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26815 invoked by alias); 20 May 2010 00:59:04 -0000 Received: (qmail 26797 invoked by uid 22791); 20 May 2010 00:59:01 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,T_RP_MATCHES_RCVD 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, 20 May 2010 00:58:56 +0000 Received: (qmail 1584 invoked from network); 20 May 2010 00:58:55 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 May 2010 00:58:55 -0000 Message-ID: <4BF48941.4090500@codesourcery.com> Date: Thu, 20 May 2010 03:29:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Tom Tromey CC: Stan Shebs , gdb-patches@sourceware.org, Jan Kratochvil Subject: Re: RFC: implement DW_OP_bit_piece References: <4BF327D2.3000802@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-05/txt/msg00405.txt.bz2 Tom Tromey wrote: > I am less sanguine about updating the tracepoint code, I suppose because > it is pretty new and yet doesn't implement even what was already in gdb > when it went in: > > if (bytes != 4) > error (_("DW_OP_piece %s not supported in location for \"%s\"."), > pulongest (bytes), SYMBOL_PRINT_NAME (symbol)); > Touche' :-) > I did dig around in the code a little, and it turns out I'm also not > clear on all the details I would need to implement the support. > > I don't really see how DWARF expressions can work with the current > setup. Maybe just some subset can -- but then I would like to > understand how the subset is chosen, I guess so I can argue against > choosing DW_OP_bit_piece ;-). Ok, seriously... > > For instance, I don't understand how a DWARF expression involving a > conditional could work. You could compile DWARF to AX, including the > condition. But then I think you'd have to circumvent the DWARF > expression when re-evaluating the expression at "replay" time (I don't > know the real name of the mode, sorry). > > In theory, evaluation of the expression while examining a trace frame will just work, because the DWARF condition will evaluate to the same value as it would have when looking at the live state. > GCC is already emitting nontrivial DWARF. It can emit some stack ops > (look at the MOD case in dwarf2out.c). It can emit pieces and stack and > literal values. And, I think it can emit TLS references. So this is > not just hypothetical, today's expression translation is already > insufficient for today's GCC. > We've been special-casing things in the ax code as they've come along in real compiler output - your mention of bit pieces got my attention because it sounded like tracepoint test cases could start regressing if someone updated their GCC. But yeah, this is the kind of thing that gets us to start muttering again about the common compilation / evaluation pathway idea. CodeSourcery's tracepoint work has already been decided for this year, and the closest related task is going to be some better handling of partially-collected values. But now is a good time to start thinking about what we should do in 2011; I can see things getting to the point where the common pathway is the easiest strategy for coping with ever-more-complex debug info from GCC. Stan