From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23090 invoked by alias); 23 Feb 2010 20:26:36 -0000 Received: (qmail 23075 invoked by uid 22791); 23 Feb 2010 20:26:35 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS 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; Tue, 23 Feb 2010 20:26:25 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1NKQKh6006671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Feb 2010 15:26:20 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1NKQJx7023195; Tue, 23 Feb 2010 15:26:20 -0500 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 o1NKQIrK022731; Tue, 23 Feb 2010 15:26:19 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 3DFD93780ED; Tue, 23 Feb 2010 13:26:18 -0700 (MST) From: Tom Tromey To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: FYI: fix big-endian bug with DWARF_VALUE_STACK References: <201002231953.o1NJrk3x018019@d12av02.megacenter.de.ibm.com> Reply-To: tromey@redhat.com Date: Tue, 23 Feb 2010 20:26:00 -0000 In-Reply-To: <201002231953.o1NJrk3x018019@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Tue, 23 Feb 2010 20:53:46 +0100 (CET)") 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-02/txt/msg00575.txt.bz2 >>>>> "Ulrich" == Ulrich Weigand writes: Tom> + store_unsigned_integer (contents + offset, n, Tom> + gdbarch_byte_order (c->arch), Tom> + p->v.expr.value); Ulrich> The original code looks broken to me too. But even the new code Ulrich> doesn't seem quite right: if the requested piece size p->size Ulrich> is larger than addr_size, the remaining bytes of the output value Ulrich> are left undefined (well, probably zeroed -- but that still doesn't Ulrich> look correct on a big-endian machine ...). I asked about a similar case on dwarf-discuss, namely what if you have: DW_OP_implicit_value[len=5] DW_OP_piece[len=10] The answer I got was something along the lines of "that is undefined, don't do that". The archives seem to be closed to the public, but if you are a subscriber you can see: http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2009-June/000760.html I think the same has to apply to your example. Ulrich> Why would that code look at gdbarch_addr_bit at all? I think this Ulrich> should simply do something like: Ulrich> store_unsigned_integer (contents + offset, p->size, Ulrich> gdbarch_byte_order (c->arch), Yeah ... I took another look and I still don't understand that use in read_pieced_value. Maybe a complaint is in order here. Tom> @@ -476,19 +474,17 @@ dwarf2_evaluate_loc_desc (struct symbol *var, struct frame_info *frame, Ulrich> Similiary here; why does this not simply use value_from_longest? It didn't occur to me; but AFAIK, nothing prohibits a DWARF expression from using DW_OP_stack_value to fill in a structure or union, and value_from_longest won't work in that case. Tom