RE: [libunwind] interest in dynamic debug-info?

[David Mosberger]

>>>>> On Sat, 18 Dec 2004 02:38:15 -0800, "Mekias, Mohamed" <address@hidden> 
>>>>> said:

  Mohamed> David, This indeed is a great addition to libunwind. We
  Mohamed> have had several situations where we needed such
  Mohamed> capability.

Glad to hear that!

  Mohamed> What is the time frame of availability for the next
  Mohamed> libunwind that supports this?

Tunneling the debug info through libunwind should be straight-forward.
I'm thinking of adding to unw_dyn_info_t a pointer to a structure of
the form:

  struct unw_dyn_debug_info {
        unw_word_t table_length;
        struct {
          const char *name;
          unw_word-t pad;
          unw_word_t size;
          unw_word_t data;
        } entry[table_length]
  }

This info would then be obtained via the unw_get_proc_info() or
unw_get_proc_info_by_ip() calls.

The table-entries would directly correspond to the various DWARF debug
info sections (.debug_info, .debug_line, .debug_abbrev, etc.).

What's creates more uncertainty is how hard it would be to get a
debugger to use this info.  I haven't looked at GDB to see if this is
easy or hard and, of course, I have no control over other debuggers.

Then there is the debug-info code-generation question.  If you're all
set up to generate debug info, I guess there is no issue but if you
wanted convenience routines to generate, say, just line info, that
would take a bit longer.

So, this whole thing is a bit of a chicken-and-egg problem: I don't
mind at all adding the debug-info tunneling to libunwind, but it's
kind of pointless until someone can actually hook it up to a dynamic
code-generator which generates debug info and a debugger that can
consume it.  If you can help with any of this (even if it's just in
the form of testing the code and giving feedback), that would
certainly help.

        --david