This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: gdb 7.2 core target setting registers rsp and friends


Hello gentle  reader!
A interesting debug scenario occurs when 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.

Perhaps this would be a simple patch that could be posted and applied
to a future release?

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...

Thanks,
dan
ps.  Was acheived by adding an 'ignore' function to to_store_registers
and to_prepare_registers for the target architecture in the early gdb
6.x timeframe?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]