Re: FYI <jkratoch/gdbserver> gdbserver-for-core branch

[Roland McGrath <roland at redhat dot com>]

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.


Thanks,
Roland