From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13366 invoked by alias); 11 May 2011 14:59:46 -0000 Received: (qmail 13343 invoked by uid 22791); 11 May 2011 14:59:46 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,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, 11 May 2011 14:59:26 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4BExJKb025672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 10:59:23 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p4BExJsl012106; Wed, 11 May 2011 10:59:19 -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 p4BExIX9006666; Wed, 11 May 2011 10:59:18 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id A5414378498; Wed, 11 May 2011 08:59:17 -0600 (MDT) From: Tom Tromey To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: RFC: implement typed DWARF stack References: <201105110015.p4B0FPSB032445@d06av02.portsmouth.uk.ibm.com> Date: Wed, 11 May 2011 14:59:00 -0000 In-Reply-To: <201105110015.p4B0FPSB032445@d06av02.portsmouth.uk.ibm.com> (Ulrich Weigand's message of "Wed, 11 May 2011 02:15:25 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (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: 2011-05/txt/msg00287.txt.bz2 >>>>> "Ulrich" == Ulrich Weigand writes: Ulrich> However, you don't really need to look specifically into Cell tests; Ulrich> with your patch applied, I'm seeing a whole bunch of test suite Ulrich> regressions in an -m32 test on ppc64. Thanks, I will look into this. Ulrich> I see. However, the code as implemented casts *all* signed values to Ulrich> unsigned for DW_OP_shr, not just old-style values. That's what got Ulrich> me confused ... Oops, thanks for noticing that. I fixed it locally. Tom> What if we add a cast to dwarf_expr_fetch_address, like the appended? Tom> I am not really sure whether this is ok. Ulrich> Huh, interesting approach. In a sense, that might be OK, since Ulrich> it mirrors what we're doing in dwarf_expr_read_reg by calling Ulrich> address_from_register. On the other hand, I'm not sure Ulrich> value_cast always does the right thing if the size of a pointer Ulrich> type differs from the size of the DWARF address type ... I had not considered that as a possibility. I think the most obviously safe thing to do is just revert dwarf_expr_fetch_address to (mostly) resemble its pre-patch state. I will do that and test it. Ulrich> Another issue that just occurred to me: your patch creates Ulrich> possibly many temporary struct value objects. I'm wondering Ulrich> whether those ought to be released from the value chain at some Ulrich> point ... I considered this but talked myself out of it using the following reasoning: 1. Most DWARF expressions are simple, so in practice not many values will be released; 2. The unwinder code is value based but does not seem to call value_free_to_mark, so it must not be significant there; 3. In other (expression-evaluation) contexts, some caller is going to free the values anyway; 4. The watchpoint code looks at the value stack to determine what intermediate values to watch, and perhaps the values from the DWARF expression are relevant (though ... it occurs to me just now that this approach must be pretty broken in the presence of location lists). I am actually not sure if #4 is an argument for or against. Maybe those intermediate values confuse things; there is a comment in value_fetch_lazy indicating that this may be the case. Tom