From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16550 invoked by alias); 8 Feb 2011 20:47:04 -0000 Received: (qmail 16542 invoked by uid 22791); 8 Feb 2011 20:47:03 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Feb 2011 20:46:59 +0000 Received: (qmail 30981 invoked from network); 8 Feb 2011 20:46:58 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Feb 2011 20:46:58 -0000 Date: Tue, 08 Feb 2011 20:47:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil Cc: dan clark <2clarkd@gmail.com>, gdb@sourceware.org Subject: Re: setting cooked registers desirable feature for coredump analysis but results in error Message-ID: <20110208204650.GA5732@caradoc.them.org> Mail-Followup-To: Jan Kratochvil , dan clark <2clarkd@gmail.com>, gdb@sourceware.org References: <20110208195334.GA14914@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110208195334.GA14914@host1.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-02/txt/msg00048.txt.bz2 On Tue, Feb 08, 2011 at 08:53:34PM +0100, Jan Kratochvil wrote: > Hello Dan, > > On Mon, 07 Feb 2011 20:01:46 +0100, dan clark wrote: > > An interesting debug scenario occurs when either a stack is corrupted > > the GDB `frame' command supports syntax `frame FRAMEADDR' and > `frame FRAMEADDR PCADDR' where FRAMEADDR should be $sp in the caller. > See the doc, this is exactly its purpose. It behaved a bit erratically now to > me on x86_64. IMO, what Dan describes is generally useful. I'd like to be able to modify both registers and memory during core file debugging, without having to deal with "set write". One way to do this would be with a new layered target. On top of "target core", add a "target scratchpad" or whatever other name you like. Then you can discard the scratchpad to get your original program back. This is very useful. For instance, suppose you're pretty-printing a variable that's slightly corrupt; you can manually un-corrupt it for inspection. -- Daniel Jacobowitz CodeSourcery