setting cooked registers desirable feature for coredump analysis but results in error

[dan clark <2clarkd at gmail dot com>]

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