From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21762 invoked by alias); 9 Jul 2002 23:00:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21753 invoked from network); 9 Jul 2002 23:00:20 -0000 Received: from unknown (HELO www.dberlin.org) (138.88.46.115) by sources.redhat.com with SMTP; 9 Jul 2002 23:00:20 -0000 Received: by www.dberlin.org (Postfix, from userid 503) id DBEA2181BE80; Tue, 9 Jul 2002 19:00:19 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.dberlin.org (Postfix) with ESMTP id 303A518003C1; Tue, 9 Jul 2002 19:00:14 -0400 (EDT) Date: Tue, 09 Jul 2002 16:00:00 -0000 From: Daniel Berlin To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: dwarf2expr.[ch] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,AWL version=2.31 X-Spam-Level: X-SW-Source: 2002-07/txt/msg00171.txt.bz2 On 9 Jul 2002, Jim Blandy wrote: > > Daniel Berlin writes: > > I also can't remember why get_subr was needed, and never implemented it. > > Refresh my memory if you could, since you wrote the spec? > > :) > > It's for DW_OP_call*, which the evaluator here doesn't implement. > > > I've only reposted it for completeness sake, i'll include it again when i > > revise the loc_computed patch. > > Actually, let's keep this evaluator discussion separate --- we can get > this reviewed and committed without dealing with anything else. Well, okay, but fair warning: either patch will take me at least a few weeks before i resubmit. While I had time back in April, law clerking is keeping me very busy, and i'm wrapped up in gcc stuff on the side. So if you have a deadline or something, .... I dunno, i just get the feeling from the sentence that you want to get this out of the way sooner than that, so i figured it's only fair i make sure you don't have the notion that i'll get to it RSN. It might make sense to cheat and do value_as_long (value_binop (value_from_long (v1), value_from_long (v2), BINOP_RSH)) etc for binops/things that need masking.or something, so we can keep the result as a LONGEST, but not worry about masking during the operations