From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18429 invoked by alias); 19 May 2010 23:34:29 -0000 Received: (qmail 18418 invoked by uid 22791); 19 May 2010 23:34:28 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Wed, 19 May 2010 23:34:23 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4JNYF4Q021129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 May 2010 19:34:15 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4JNYDWd003794; Wed, 19 May 2010 19:34:13 -0400 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 o4JNYChI018554; Wed, 19 May 2010 19:34:12 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id D160A37818E; Wed, 19 May 2010 17:34:11 -0600 (MDT) From: Tom Tromey To: Stan Shebs Cc: gdb-patches@sourceware.org, Jan Kratochvil Subject: Re: RFC: implement DW_OP_bit_piece References: <4BF327D2.3000802@codesourcery.com> Reply-To: Tom Tromey Date: Wed, 19 May 2010 23:35:00 -0000 In-Reply-To: <4BF327D2.3000802@codesourcery.com> (Stan Shebs's message of "Tue, 18 May 2010 16:50:42 -0700") 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: 2010-05/txt/msg00402.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> Your code looks reasonable, but you're missing two, uh, pieces :-) - Thanks. Stan> the dwarf2_tracepoint_var_ref code to compile to bytecodes, and Stan> human-readable description in locexpr_describe_location_1. Stan> (Yes it's onerous, but we did want to revive tracepoints, right?) I will update locexpr_describe_location_1. 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)); 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). 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. Tom