softint overhead: splx .vs. interrupt

Given how many splx calls the kernel does, what's less overhead?

Checking for pending softint in splx or just blasting COP_0_STATUS and letting an interrupt happen?

An interrupts is several hundred instruction. Testing for a softint is a few but it also makes splx a nested function and calling softint_process would be another dozen or instructions. Guessing, I'd say there's a few hundred splx between each softintr so that maybe the interrupt is cheaper. Probably should measure that...

kernel crash dump use ELF core file format.

NetBSD currently dumps its kernel crashes in a NetBSD specific format. This requires gdb to know how to read them (and be linked against libkbm).

Instead, NetBSD should dump kernel core dumps as a ELF core dump (just like any other application). User pages would not be dumped. There would be a note section for each LWP allowing automatic viewing of the LWP's register using the normal gdb thread command (encoding the thread id might get tricky for system LWPs or processes with multiple LWPs).

ELF phdrs would be written so that gdb can automagically map kernel virtual addresses to physical addresses (including direct mapped pages for PMAP_MAP_POOLPAGE support). This may require a lot of phdrs but that's true even for normal ELF core files.

cored

The coredump code in the kernel is already writes the core dump in a single pass over
a file descriptor. This was done so that coredumps could be written directly to a pipe or socket as well as a file. Currently, though, it just writes to a file.

This project would add support for sending a message to a crash daemon which would use a config file to determine what happens next. For instance it could decide to write the crashdump to a pipeline of |gzip -v | ssh ... or maybe directly to a socket used for a http put. This would enabled embedded NetBSD to save coredumps remotely automagically.

AF_GDB / GDB socket

I hate ptrace. But before killing it I need something to replace it. I could use a procfs style interface with ioctls but that's a complex interface.

Instead I want to use the GDB protocol over an AF_GDB socket. It would use socket(AF_GDB, SOCK_STREAM, pid) to connect to the process to be debugged.

To do a run command in gdb, gdb will fork, connect to its child, request a message for "exec", and continue the child. When the child execs the program gdb will grab control of the new process and proceed from there.

As part of this effort, connecting to pid 0 would enable gdb access to the kernel (mostly as a tools to examine memory and threads; no breakpoints would be allowed).