From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1222 invoked by alias); 28 Mar 2011 09:20:55 -0000 Received: (qmail 1208 invoked by uid 22791); 28 Mar 2011 09:20:54 -0000 X-SWARE-Spam-Status: No, hits=-6.4 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; Mon, 28 Mar 2011 09:20:49 +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 p2S9KmLS023126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2011 05:20:48 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p2S9Km7c016536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2011 05:20:48 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p2S9Kls4003956; Mon, 28 Mar 2011 11:20:47 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p2S9Kjlk003953; Mon, 28 Mar 2011 11:20:45 +0200 Date: Mon, 28 Mar 2011 09:25:00 -0000 From: Jakub Jelinek To: Roland McGrath Cc: Richard Henderson , Jason Merrill , Cary Coutant , gcc-patches@gcc.gnu.org, Jan Kratochvil , Tom Tromey , Mark Wielaard Subject: Re: [RFC PATCH] Typed DWARF stack Message-ID: <20110328092045.GH18914@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <20110325113237.GY18914@tyan-ft48-01.lab.bos.redhat.com> <20110325164440.A09BC2C15B@topped-with-meat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110325164440.A09BC2C15B@topped-with-meat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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-03/txt/msg01873.txt.bz2 On Fri, Mar 25, 2011 at 09:44:40AM -0700, Roland McGrath wrote: > It's been a while since I read Cary's proposal, and I am no longer > likely to do much work of my own in this area. So I'll just respond at > the high level. > > I like very much the essential notion of the stack being of typed > entities with no specification of how the consumer actually implements > it. In particular, this also brings implicit-pointer into the fold as a > new type of a stack element, i.e. "imaginary pointer". Obviously only > the operations that amount to addition/subtraction with an integer > actually make sense on such a stack element. This makes the second > operand of DW_OP(GNU_)implicit_pointer superfluous (and hence the common > case of zero a byte smaller), since nonzero cases can just be followed > by an appropriate DW_OP_plus_uconst or suchlike. For DW_OP_GNU_implicit_pointer it is too late to remove the parameter now, because e.g. GCC 4.6 has been shipped with it and several tools have support for it already. What we still could do is reword it based on the typed stack, say that DW_OP_*implicit_pointer pushes an entry of a special type on the stack and what operations are allowed with that type (from arithmetics I think only addition of integral stack value to it (leading again to implicit pointer type) or subtraction of two implicit pointers for the same DIE, leading to an integral difference. With that rewording, DW_OP_GNU_implicit_pointer could be no longer a terminal, but could appear within the DWARF expressions. DW_OP_implicit_pointer can of course be designed without the operand. > As to encoding, I have a fancy idea that I discussed off the cuff at the > Summit with Jakub and Richard, and still quite like, though I haven't > fleshed it out any more than I did then. I hope to inspire someone else > to actually want to implement it. It's rather more ambitious than the > things that Jakub will just add while the rest of us sleep, so I > wouldn't suggest that such DW_OP_GNU_* extensions be delayed for this > plan. But perhaps it can become coherent enough and get done enough to > seriously propose it for DWARF 5. I view such encoding changes primarily as compression and thus IMHO we don't need to delay any changes waiting for the compression technique specification. We have DW_OP_call{2,4} right now as a simple compression technique and can (and should) improve that, but in the mean time we can just add new ops as we'd normally do. > As I say, I'm not really working on this stuff any more except maybe for > (as yet wholly absent) spare time. But, food for thought. IMHO the typed stack as Cary proposed is usable as is, and as additional bonus it is extensible, e.g. by saying that the referenced DIE doesn't have to be just DW_TAG_base_type, but also this and that (where the referenced DIE tags could newly be either current tags where we would give it a particular meaning, or it could be some newly added tag, perhaps just for that purpose) we could extend it easily. Jakub