Using GDB to debug a user space process in UML

[YiFei Zhu]

  On Fri, Oct 8, 2021 at 9:46 AM Glenn Washburn
<development at efficientek.com> wrote:
> Wow, thanks for that response! After reading your excellent and detailed
> response, I'm thinking perhaps all is not lost. One idea is to have a
> mode, perhaps set by a commandline flag called init_debug, where if the
> init process recieves a signal that would make a coredump, the process
> is stopped and the tracing thread stops ptracing it. There could be a
> message output which says something like "Init PID <pid> has crashed,
> been stopped, and waiting to be attached by debugger."
>
> I make this init process specific because other processes should be
> debuggable via gdb inside the UML instance. Also it might be painful if
> the terminal isn't setup right. But I don't see why it couldn't be
> extended to the same behavior for all processes. Yes, this might cause
> a bunch of unreaped dead processes hanging around, but I think that's
> acceptable considering this is a debug mode.

Some more ideas: completely untested, feel free to try out.

* When the kernel is about to panic to PID 1 dying, instead of
actually dying, send PID 1 SIGABRT, then go into an infinite loop. I
don't exactly know the signal handler list on UML user space
processes, but if that doesn't work making userspace_trampset the
signal handler to SIG_DFL should work in theory.
* For an unhandled SIGSEGV, coredump happens before the process exits
[1] which causes the kernel to panic, so if, instead of calling group
exit during the signal handling, you go into infinite D sleep. The UML
kernel might be able to get the coredump saved if wherever filesystem
it is writing to is writable.
* On the host, even though UML user space processes are being ptraced,
/proc/pid/mem is still readable, so in theory, one could construct
some sort of core dump based on /proc/pid/mem.

Note though, if the coredump is on the host, all the memory maps are
like /dev/shm/#123456 which isn't useful in determining what files are
mapped where. And like Johannes said, this just dumps the address
space of a UML process, which isn't as useful as a real coredump.

[1] https://elixir.bootlin.com/linux/v5.14.10/source/kernel/signal.c#L2782

Oh btw, UML kernel segv handler probably isn't a great place to do the
hooking. UML, like a normal kernel-mode Linux kernel, loads pages into
a process's address space lazily. So it is quite noisy even with
normal operation.

YiFei Zhu