From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26895 invoked by alias); 1 Apr 2002 19:00:37 -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 26888 invoked from network); 1 Apr 2002 19:00:36 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 1 Apr 2002 19:00:36 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 7FED25EA11; Mon, 1 Apr 2002 14:00:34 -0500 (EST) To: Daniel Berlin Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI References: From: Jim Blandy Date: Mon, 01 Apr 2002 11:00:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00004.txt.bz2 It may well be overengineered. A libdwarf is indeed what I had in mind; I thought it might be nice to start putting together the pieces for it. Daniel Berlin writes: > In particular, you just need some initial value, or no initial value, not > a push object address value/other types of things that may get pushed to > the front. Well, DW_AT_data_member_location expressions want the base address of the innermost enclosing structure on the stack, whereas DW_AT_use_location expressions want the pointer-to-member value and the object's base address on the stack. So we've got situations which need zero, one, and two values on the stack. So it seems like the basic interface should let people push as much as they want. > Also, why would something need our evaluator if they already knew how to > read DIE's at a given offset? It's very likely they can also evaluate > expressions if they can read DWARF2 at all. Well, to share code, I guess. They'd toss their interpreter to use ours, and spread the maintenance job around. I have no clients in mind, just general principle. When we've got something whose behavior is well-specified with no reference to GDB, it just seems like good practice to produce an implementation that, likewise, is independent of GDB. > If, however, this is what GDB people want it to look like, i'll happily > implement it. It's not like it'll be that much more work for me. I'd approve it. :)