From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20017 invoked by alias); 28 Mar 2002 21:12:52 -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 20006 invoked from network); 28 Mar 2002 21:12:51 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 28 Mar 2002 21:12:51 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id A37B95EA12; Thu, 28 Mar 2002 16:12:49 -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: Thu, 28 Mar 2002 13:12: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-03/txt/msg00588.txt.bz2 Daniel Berlin writes: > I didn't want to deal with the issue of whether we want to return a struct > value, and the issue of how best to keep track of whether it's in memory > or a register, without getting an opinion first. I spoke with Andrew on the phone yesterday, and he and I have different ideas about how things should go. I don't think I understood the path of changes he wanted to see. My personal inclination is to make the Dwarf 2 location expression interpreter as independent from GDB as possible. It can use the CORE_ADDR type for stack elements, but it should take arguments specifying: - the expression as a simple char * pointer and length, - the architecture's address size, - function pointers for reading memory and registers that simply hand back a CORE_ADDR value (thus keeping the interpreter innocent of endianness issues), and - the frame base address (for DW_OP_fbreg) It should return a structure that says whether the location expression specified a particular register (i.e., DW_OP_reg0 and friends) or an address. Actually, the return value should be a list of pieces, each of which gives a byte length and then a register or address. But I tend to think it shouldn't take a struct frame_info or struct context, and it shouldn't return a struct value. Sure, you'll need more glue code than you would if it took just the right arguments for the use we have in mind, but keeping it as innocent of GDB as possible makes the interface easier to understand: you don't need to wonder how it interacts with a frame's saved registers, how it finds the frame base, and so on. You can look at the code and say, "Ah, this doesn't worry about any of that." There's a simple test for the module boundaries: if a behavior is described in the Dwarf spec chapter on location expressions, it should be inside; otherwise, it should be outside. And once you've written frame/struct value glue code, everyone can use that and nobody minds. What a lot of hand-waving. Sorry. Hopefully you'll see what I'm getting at.