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

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

[dan clark]

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

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

[Jan Kratochvil]

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

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

[Daniel Jacobowitz]

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

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

[dan clark]

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
<jan.kratochvil@redhat.com> 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
>