gdbserver with a core file?

gdbserver with a core file?

[Paul Smith]

Has anyone every considered, or actually implemented, the ability to
use gdbserver to debug a core file remotely in addition to debugging
live processes?

More and more I'm seeing core files dumped on AWS or Google Cloud
instances.  It's really expensive (and slow!!) to copy these many-GB
cores back to my local system for debugging, and they're often only
needed for an hour or so.

Of course I could debug them in the cloud, but either I need to go
without source code during debugging or I need to copy my source code
into the cloud, neither of which is particularly appealing for all
kinds of reasons.

When I was working on embedded systems gdbserver was a lifesaver, and
it would save me a lot of time (and $$) if I could debug core files
with it.

Any thoughts on this?

RE: gdbserver with a core file?

[taylor, david]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 915 bytes --]

I don't know if anyone has added such functionality to gdbserver; but, with regards to
the problem you're trying to solve -- I've faced similar ones in the past.

If you use emacs, you might consider gud plus a small shell script or two.

I've used in in the past to solve the problem where I have GDB and the executable
remote but sources local.

In emacs, do

M-x gdb

when prompted for how to run gdb, replace gdb with the path to a shell script that

. sets up the local environment (if needed)
. invokes ssh -- something like:

    ssh remote-host /path/to/remote/shell/script

where the remote shell script does a cd if needed, creates a gdb init file if appropriate
and / or needed, and then invokes gdb with appropriate arguments.

GDB communicates with Emacs.  When you stop / step / next / whatever,
GDB tells Emacs what it needs to know.  Sources stay local.
\x16º&ÖëzÛ«ŸŽ·ãÉb²Ö«r\x18\x1d