From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 487 invoked by alias); 24 Feb 2010 14:12:03 -0000 Received: (qmail 472 invoked by uid 22791); 24 Feb 2010 14:12:02 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.17.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Feb 2010 14:11:57 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.1/8.13.1) with ESMTP id o1OEBsi0001915 for ; Wed, 24 Feb 2010 14:11:54 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1OEBsET1683506 for ; Wed, 24 Feb 2010 15:11:54 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o1OEBsOu011392 for ; Wed, 24 Feb 2010 15:11:54 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o1OEBrHC011378; Wed, 24 Feb 2010 15:11:53 +0100 Message-Id: <201002241411.o1OEBrHC011378@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 24 Feb 2010 15:11:53 +0100 Subject: Re: FYI: fix big-endian bug with DWARF_VALUE_STACK To: tromey@redhat.com Date: Wed, 24 Feb 2010 14:12:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Tom Tromey" at Feb 23, 2010 01:26:17 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-02/txt/msg00590.txt.bz2 Tom Tromey wrote: > >>>>> "Ulrich" == Ulrich Weigand writes: > 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". This seems somewhat different in that the DW_OP_implicit_value explicitly provides data of a certain length. On the other hand, DW_OP_stack_value refers to the value on top of the stack, which -as I understand it- is a numerical value, not a sequence of bytes of defined length. So it would seem to me that you should be able to request that this value be represented in any arbitrary length ... However, maybe I'm missing something here, in particular as I haven't been able to find a formal specification of DW_OP_stack_value -- I assume this is in the current DWARF4 draft? Is this available somewhere? > 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. OK, good point, so you'd have to use store_unsigned_integer directly. Still, the reference to ctx->addr_size seems odd to me ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com