From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27287 invoked by alias); 3 May 2006 14:40:00 -0000 Received: (qmail 27276 invoked by uid 22791); 3 May 2006 14:40:00 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 03 May 2006 14:39:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FbIW8-0001aa-JH; Wed, 03 May 2006 10:39:52 -0400 Date: Wed, 03 May 2006 14:40:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: GDB Patches Subject: Re: [PATCH] Allow writing to registers before the program starts Message-ID: <20060503143952.GA5965@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , GDB Patches References: <4458B803.5050506@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4458B803.5050506@st.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00018.txt.bz2 On Wed, May 03, 2006 at 03:02:43PM +0100, Andrew STUBBS wrote: > Reverting the valops.c portion of this patch solves the problem for me. > I have tested it and it produced no regressions. > > Ok to apply the attached reversion? No, this patch is incorrect. I don't recall exactly why, but I think it will mess up writing to the saved registers after using "up". I happen to know the actual cause of the problem you're trying to fix; there's a nasty hack in CodeSourcery's branch to fix it, but the real fix is more work than I've had time for yet. It's a representation problem. As a starting point, here's my fix for the same problem: Index: frame.c =================================================================== RCS file: /cvs/src/src/gdb/frame.c,v retrieving revision 1.211 diff -u -p -r1.211 frame.c --- frame.c 17 Dec 2005 22:33:59 -0000 1.211 +++ frame.c 2 Apr 2006 02:31:24 -0000 @@ -395,16 +395,26 @@ frame_find_by_id (struct frame_id id) { struct frame_info *frame; +#if 0 /* ZERO denotes the null frame, let the caller decide what to do about it. Should it instead return get_current_frame()? */ if (!frame_id_p (id)) return NULL; +#endif for (frame = get_current_frame (); frame != NULL; frame = get_prev_frame (frame)) { struct frame_id this = get_frame_id (frame); +#if 1 + /* We use an invalid frame id to mean "could not unwind from + here"! This hack fixes the "value being assigned to is + no longer active" problem. This strongly suggests that + we need to change the representation. */ + if (!frame_id_p (id) && !frame_id_p (this)) + return frame; +#endif if (frame_id_eq (id, this)) /* An exact match. */ return frame; Basically, the problem comes about because we signal the end of the stack by returning an invalid frame ID from ->this_id in the unwinder. But we also use invalid IDs in various places to mean "no frame at all" or "no frame in particular". I think this causes trouble in other places as well. For instance you can't use outer/inner on the ID of the last frame. Sometimes, we don't have any idea what ID to use for the last frame. We use the null ID in that case. This is somewhat reasonable, but could be problematic - we can't tell it apart from a completely different frame that we can't unwind either. The opposite could also be problematic; using $sp might mean the frame ID changes unexpectedly when we're within the same logical frame. Maybe use a different sentinal ID than the current one. But it's the other case that I find more interesting. A lot of the times we know exactly what this frame's ID is, but have made a conscious decision to stop unwinding (e.g. because the next frame's stack pointer would be a sentinel value). If we had a different way to signal "stop unwinding here" but return a valid ID... I think much of this awkwardness would go away. -- Daniel Jacobowitz CodeSourcery