From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11463 invoked by alias); 7 Feb 2011 19:01:56 -0000 Received: (qmail 11311 invoked by uid 22791); 7 Feb 2011 19:01:55 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_EG,T_TO_NO_BRKTS_FREEMAIL 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; Mon, 07 Feb 2011 19:01:48 +0000 Received: by ywj3 with SMTP id 3so2203775ywj.0 for ; Mon, 07 Feb 2011 11:01:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.125.1 with SMTP id x1mr9799502anc.82.1297105306052; Mon, 07 Feb 2011 11:01:46 -0800 (PST) Received: by 10.100.134.11 with HTTP; Mon, 7 Feb 2011 11:01:46 -0800 (PST) Date: Mon, 07 Feb 2011 19:01:00 -0000 Message-ID: Subject: setting cooked registers desirable feature for coredump analysis but results in error From: dan clark <2clarkd@gmail.com> To: 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/msg00042.txt.bz2 Hello Gentle readers! An interesting debug scenario occurs when either a stack is corrupted or a threading package is unknown by gdb (anything but pthreads?) and one is left with the binary and a core dump. Let's say this was a remote system so one can't just re-run the program. A method of getting some more information out of the resulting entrails is to pick through known data structures and locate a promising stack pointer, stack base pointer and program counter. Set the values in GDB and type 'where 2' to see if the stack unwinds from that point would be a very desirable feature. Unfortunately GDB 7.2 does not allow registers to be written for core files. When attempting to set a register value an error is returned. (gdb) set $rsp=$anaddress You can't do that without a process to debug. Clearly setting the hardware device registers is can not be done, but setting the gdb notion of the registers for analysis of the core dump could be achieved to facilitate analysis of the entrails. Perhaps a simple patch could be developed to provide such functionality? Would the correct place to add such a change be: corelow.c init_core_ops() ... core_ops.to_store_registers = core_store_inferior_registers; core_ops.to_prepare_to_store = core_prepare_to_store; Seems like the prepare could be simple null function: static void core_prepare_to_store (struct regcache *regcache) { } But that leaves the slightly more difficult static void core_store_inferior_registers (struct target_ops *ops, struct regcache *regcache, int regnum) { gdb_gregset_t gregset; /* modify the proper register values here... */ regcache_raw_supply(regcache, regnum, (char *)&gregset); } Any suggestions on what an implementation might look like to achieve debug of a core file? The above, btw, does not modify the cooked registers within gdb so info reg are unfortunately not modified quiet so easily... This was supported by adding an 'ignore' function to to_store_registers and to_prepare_registers for the target architecture in the early gdb 6.x timeframe. How would it be done in the 7.x codebase? Thanks for any suggestions! dan ps. repost from patches-gdb