From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23679 invoked by alias); 9 Feb 2011 21:31:14 -0000 Received: (qmail 23671 invoked by uid 22791); 9 Feb 2011 21:31:13 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com) (209.85.213.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Feb 2011 21:31:09 +0000 Received: by ywj3 with SMTP id 3so313183ywj.0 for ; Wed, 09 Feb 2011 13:31:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.228.19 with SMTP id a19mr6024918anh.218.1297287067504; Wed, 09 Feb 2011 13:31:07 -0800 (PST) Received: by 10.100.134.11 with HTTP; Wed, 9 Feb 2011 13:31:07 -0800 (PST) In-Reply-To: <20110208195334.GA14914@host1.dyn.jankratochvil.net> References: <20110208195334.GA14914@host1.dyn.jankratochvil.net> Date: Wed, 09 Feb 2011 21:31:00 -0000 Message-ID: Subject: Re: setting cooked registers desirable feature for coredump analysis but results in error From: dan clark <2clarkd@gmail.com> To: Jan Kratochvil Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00053.txt.bz2 Hi Jan! Thank you for your suggestions and support! Indeed as you say both the program counter (pc/rip) and the stack pointer (sp/rsp) can be passed through to setup an arbitrary starting point with the 'frame' command. Unfortunately this appears to be insufficient to provide a reasonable back trace. It appears that it is not until the frame pointer (ebp/rbp) register is set that the trace works. The frame.c 'create_new_frame()' call was easy to enhance to pass in the third register value but unfortunately when attempting to set the new sentinal_frames register value for the frame pointer it results in the same error that does not allow registers to be modified for a core dump analysis. Is there a code change in create_new_frame that would allow the frame pointer value to be passed in? Is there a way of allowing the full set of registers to be manipulated to provide a more flexible use of gdb when analyzing core dumps? Thanks again for your ideas and response! dan On Tue, Feb 8, 2011 at 11:53 AM, 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. > > If/as this is not a common task one can use `eu-readelf -n corefile' > (eu-readelf is readelf from elfutils) and patch the registers using hexedit, > IIRC I was doing to before. > > > Regards, > Jan >