From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2543 invoked by alias); 4 Sep 2009 17:49:12 -0000 Received: (qmail 2533 invoked by uid 22791); 4 Sep 2009 17:49:11 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Sep 2009 17:49:06 +0000 Received: (qmail 23584 invoked from network); 4 Sep 2009 17:49:03 -0000 Received: from unknown (HELO localhost) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Sep 2009 17:49:03 -0000 Date: Fri, 04 Sep 2009 17:49:00 -0000 From: Nathan Froyd To: Tom Tromey Cc: Doug Evans , Pedro Alves , gdb@sourceware.org Subject: Re: store.exp failure on i686-linux with newer gcc's Message-ID: <20090904174903.GV29075@codesourcery.com> References: <200909032303.56901.pedro@codesourcery.com> <20090903234357.GR29075@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00077.txt.bz2 On Fri, Sep 04, 2009 at 10:04:39AM -0600, Tom Tromey wrote: > Nice patch. Thanks. > Nathan> +static void > Nathan> +write_pieced_value (struct value *to, struct value *from) > Nathan> +{ > [...] > Nathan> + struct frame_info *frame = frame_find_by_id (VALUE_FRAME_ID (to)); > Nathan> + > Nathan> + if (frame == NULL) > Nathan> + { > Nathan> + set_value_optimized_out (to, 1); > > What impact does this have on the error messages the user sees? > I didn't try to trace through the code; will setting a variable in this > scenario give an error? (Or silently do nothing?) > > Second, this seems like a change in behavior for the value history. > Suppose the user does "print local", which uses this machinery. > Then the inferior exits. Then the user does "print $1" or whatever... > this ought to print the same value, but now I think the user will get an > error. I'm not really sure if that case is even reachable (likewise for the read case); I'd be happy to consider scenarios where it might be. If you do something like: (gdb) break foo (gdb) cont (gdb) p local $3 = ... (gdb) finish (gdb) p $3 that works just fine. Similarly if you let the inferior finish. Writing to $3 is disallowed ("Left operand of assignment is not a modifiable lvalue.") I think everything works as you would expect. > So, perhaps it is better to continue to copy in the bits eagerly > instead of postponing them to read_pieced_value. I'm not exactly sure what you mean here. At least for values where some of the pieces live in registers, if you don't have the frame for the value, you can't write to the register, correct? -Nathan