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

[dan clark <2clarkd@gmail.com>]

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
>