Re: Executing code if debuggee is a crash dump?

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-08-24 6:07 a.m., Michael Woerister via Gdb wrote:> Hi everyone,
> 
> I'm looking into implementing debugger extensions that help with debugging crash dumps of "async" Rust executables. Such an extension would need to inspect the complex internals of several async runtime implementations. We could potentially make the extension more robust and easier to maintain if we provided a standardized inspection API in the various runtimes and have the debugger interact with that. The functions behind this API would be restricted to not interact with the environment (e.g. not allocate memory, etc).
> 
> However, my research so far indicates that neither GDB nor any other debugger is capable of executing code in a crash dump. Is that true or am I overlooking something?
> Would anybody here be able give me a definite answer to this question?
> 
> Thanks a lot for your help!
> 
> -Michael
> 

Hi Michael,

Indeed, when inspecting a crash dump in GDB, there's no live process,
so you can't do function calls in it.  That's one of the downsides of
relying on function calls to build pretty printers and other tools that
extract data from debugged programs.

I've sometimes heard the idea of creating a live process from a crash
dump state, but I have never seen it implemented.  In theory, if that
existed, that would allow you to do function calls.  But there is some
state that can't really be restored, like file descriptors, so that
limits what you can do.  Another downside of that is that you wouldn't
be able to inspect a core dump on a different architecture than what the
core dump was created on (something that is useful for embedded
devices).

So people often end up using some GDB / Python code that has the
knowledge of the program's internal data structures.  For example, the
Linux kernel:

    https://github.com/torvalds/linux/blob/master/scripts/gdb/vmlinux-gdb.py

Simon