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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
