That's a cute hack. I'm not really sure what it's for, but here's my
guess: You'd replace shipping a whole core file to someplace with a full
gdb environment (debuginfo, appropriate python hooks, etc.) by instead
connecting that far-off gdb back to this lightweight stub to read
interactively read out only the bits of the core file gdb really needs.
Two tangents for discussion come to mind.
1. GDB register numbers. The built-in arch maps are obviously an
undesireable kludge. To do the same thing cleanly in the elfutils
world, you'd add the knowledge to the libebl backends instead. You
could just add a field to Ebl_Register_Location for GDB number. Or you
could add a separate backend hook that maps between GDB numbers and
DWARF numbers, or something like that.
I never considered GDB register numbers in the libebl stuff before,
mostly because the need just never came up before, but also because all
the elfutils stuff has stayed pretty well "pure" in using terms defined
by ELF, DWARF, and "target native" layout stuff. The GDB numbering is
yet another variant of the same data, which IMHO ideally should die in
favor of DWARF numbering and/or target note layouts--that's enough
arch-dependent knowledge to carry around already. (If GDB had not
predated DWARF and ELF note formats, I'm sure it never would have grown
its own register numbering scheme in the first place.) But since via
the remote protocol, those internal GDBisms do leak out to become an ABI
of sorts, perhaps we should just represent them too. Either way, the
libebl hook interfaces are intentionally not permanent APIs/ABIs for the
elfutils libraries, so it's not really a big deal to add or change details.
OTOH, another tack would be to excise the use of GDB register numbers
from the remote protocol. I'm pretty sure I previously posted on the
archer list about this. The remote protocol could grow some extensions
to exchange register data in terms of target layouts (identified by
n_type codes). Then the stubs would not need any such arch knowledge
(reducing their total arch knowledge to nearly none). That is, the core
reading stub, ugdb, and traditional gdbserver using PTRACE_GETREGSET (on
recent kernels). Of course, that is not a solution that helps with
extant clients of the remote protocol (including extant GDB versions).
Incidentally, I previously planned (and once had some code for) some
libdwfl interfaces to handle the mapping of DWARF register numbers to
the target layouts easily. That is, something programmer-friendly that
is driven by that libebl backend data. I haven't found a reason to
revive that code and really settle on all the API details.
2. Threads. Have you considered making the stub support multiple threads?
If the only actual use is for crash backtraces, then you don't really
care since Linux writes the first set of register notes for the thread
that instigates the crash and performs the dump-writing. But more
sophisticated crash analysis may want to know what the other threads
were doing when the program died.
I've previously contemplated giving libdwfl a first-class concept of
threads in a Dwfl, parallel to its segments. That is, in general they
would just be a mapping of enumerable thread identifiers to some hook
for data. The only particular pre-fab organization of such data would
be to have per-thread and process-wide (i.e. Dwfl-wide) notes. For
fancy users of libdwfl, this is just a trivial facility for whatever
data they keep track of themselves, and its only real purpose is a
common API pivot point for providers and consumers of thread data.
The libdwfl core-reading support would populate a Dwfl with threads
and notes from the core file as it populates it with segments today.
Other new library code (probably not in libdwfl proper) could support
live thread data via ptrace, its successors, or other such things.
Then front-end code would use the libdwfl interfaces to get at the
threads and their notes (and the process-wide notes like NT_AUXV) and
thus apply equally to core-reading and various other backends.