From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10623 invoked by alias); 4 May 2011 18:22:26 -0000 Received: (qmail 10392 invoked by uid 22791); 4 May 2011 18:22:24 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 May 2011 18:22:10 +0000 Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p44IM6LL007254 for ; Wed, 4 May 2011 11:22:06 -0700 Received: from yia25 (yia25.prod.google.com [10.243.65.25]) by hpaq12.eem.corp.google.com with ESMTP id p44IKQav024056 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 4 May 2011 11:22:05 -0700 Received: by yia25 with SMTP id 25so584853yia.12 for ; Wed, 04 May 2011 11:22:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.207.30 with SMTP id j30mr932357anq.86.1304533324625; Wed, 04 May 2011 11:22:04 -0700 (PDT) Received: by 10.100.131.8 with HTTP; Wed, 4 May 2011 11:22:04 -0700 (PDT) In-Reply-To: References: <20110325113237.GY18914@tyan-ft48-01.lab.bos.redhat.com> Date: Wed, 04 May 2011 18:30:00 -0000 Message-ID: Subject: Re: [RFC PATCH] Typed DWARF stack From: Cary Coutant To: Tom Tromey Cc: Jakub Jelinek , Richard Henderson , Jason Merrill , gcc-patches@gcc.gnu.org, Roland McGrath , Jan Kratochvil , Mark Wielaard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg00335.txt.bz2 > Should DW_OP_bra be restricted to integral types? =A0Several other opcodes > are restricted in this way, and it seems like an oversight to me that > DW_OP_bra is lacking this restriction. =A0(I've added this restriction in > GDB.) Yes, that was an oversight. > Currently, the comparison operators are all defined as performing signed > operations. =A0So, what should happen in this case: > > =A0 DW_OP_lit0 > =A0 DW_OP_GNU_convert > =A0 DW_OP_GNU_const_type -1 > =A0 DW_OP_gt > > That is, should this ignore the type (perhaps just using the type > width), or is this a bug in the spec? > > Either answer here has problems. > > You can't really ignore the type, because that rules out floating point > comparisons. =A0I suppose you could special-case integral types. > > However, since "ordinary" (that is, pre-typed-DWARF) DWARF values do not > have a consistent type, I think answering "bug" means having a special > case for such values -- because they are treated as unsigned in most > places, but signed in a few, and signed/unsigned type conversion should > presumably only be done for such "typeless" values, not all values. > > I think I will implement the latter ("bug") approach. Yes, another oversight; I should have removed the sentence "The comparisons are done as signed operations." For untyped values, it should be reasonable to treat them as signed integers here as you propose. Technically, there weren't supposed to be untyped values at all in this proposal; I should have also gone through and specified an explicit type for each of the legacy operators that push a value onto the stack, but signed-vs-unsigned is such a mess that I didn't bother to go that far for a draft proposal that didn't get very far in committee. I think a signed/unsigned cleanup in DWARF would have to go far beyond the expression evaluation mechanism. -cary