From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28352 invoked by alias); 27 Mar 2002 03:17:15 -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 28320 invoked from network); 27 Mar 2002 03:17:14 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 27 Mar 2002 03:17:14 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g2R3HDm13762; Tue, 26 Mar 2002 22:17:13 -0500 Date: Tue, 26 Mar 2002 19:17:00 -0000 From: Daniel Berlin To: Jim Blandy cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-03/txt/msg00525.txt.bz2 On 26 Mar 2002, Jim Blandy wrote: > > Daniel Berlin writes: > > On 26 Mar 2002, Jim Blandy wrote: > > > Actually, Daniel, I'm sorry --- I've re-read the change more > > > carefully, and I've gotten more confused than I was before. > > > > > > You've changed the Dwarf 2 location expression evaluator to consult > > > the current register values --- not the values of the registers with > > > respect to a specific stack frame. I can't think of any situations in > > > which this the correct behavior. Can you explain more about the > > > contexts in which this change is useful? It seems to me that it's > > > wrong in most of the cases I can think of. It really needs to take a > > > frame argument, or at the very least, read registers from the selected > > > frame (although that's kind of gross and global-variable-ish). > > > > Whoops. > > You're right. > > I must have merged it while on crack or something. > > I *meant* to add the frame argument, and only require *either* the > > context argument (Which is what it currently takes, a CFA context) or the > > frame, but it looks like I messed up. > > > > What it *should* look like is closer to the one from the WIP i sent. It > > should call get_saved_register with the frame argument if the context is > > null, or get_reg with the context argument if the context is not null. > > Okay --- that makes more sense. > > I started reviewing the WIP, but I got interrupted. Do you want to > extract something from that and post it as a non-WIP patch? I'm not sure. Let me explain: As it stands, the evaluator in the WIP requires a few extra arguments and returns a struct value, while the the one in dwarf2cfi does not. The extra arguments are required because we need to keep track of whether the result is an lval or not, and whether the result is in memory or a register, so we can set the approriate flags on the value struct But i'm not sure this is the right approach. This is why the first patch was meant only to make it external, take either a dwarf2 cfa context, or a struct frame info, and do the right thing with either, in terms of handing back a location. 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. So, in short, if the approach taken by the WIP evaluator is the right way to deal with the issue of needing to be able to set the right flags on a struct value, than sure, i'll take that part out, and merge it. Otherwise, I'd rather make sure the version in the repository is changed the right way, merging in the other direction to the WIP. --Dan