Re: [libunwind] Some basic questions about libunwind

[David Mosberger]

>>>>> On Sat, 20 Nov 2004 21:22:01 -0600 (CST), Archie Cobbs <address@hidden> 
>>>>> said:

  Archie> I'm looking at the possibility of using libunwind for JC, a Java
  Archie> VM implementation (http://jcvm.sourceforge.net), and have some basic
  Archie> questions, as I'm still a bit unsure about how it would all work.

That sounds quite interesting.  I'm no Java expert but I'm curious how
it compares to GCJ.  We found that GCJ somtimes performs rather poorly
compared to modern JITs.  Perhaps JC would do better?

  Archie> Use of libunwind in JC would be limited strictly to:

  Archie> (a) Crawling the stack (local only) to retrieve, from each frame:

  Archie> - Saved PC (return address), for identifying the function
  Archie> (JC already knows how to map PC -> function if that helps)

  Archie> - Contents of saved registers, for computing the root set
  Archie> of object references for garbage collection purposes.

OK, libunwind certain can do that.  I wonder though: wouldn't it be
easier to just take a snapshot of the current preserved registers
(e.g., via getcontext()) and then search the entire stack for values
that look like pointers?  (I'm definitely happy if the answer is "no";
just trying to understand why a stack-walk is necessary here.)

  Archie> (b) The 'turbo' setjmp/longjmp capability (for throwing
  Archie> exceptions)

OK.  Since x86 has so few registers, I'm not sure it'll make a huge
difference.  I think we're talking about storing 24 bytes with the
regular setjmp and 8 bytes with libunwind-setjmp.  If the 24 bytes
straddle a cache-line boundary, it could make a measurable difference.
The win is probably more noticable for x86-64, where the difference is
64 bytes vs. 16 bytes.

  Archie> Sorry for the slew of basic questions and thanks in advance
  Archie> for any answers to the following...

  Archie> 1. What is the state of x86 (32 bit) support in libunwind
  Archie> with respect to the above requirements?

I'd say "improving".  I'm actively working on it.

  Archie> 2. What is the state of DWARF2 support in libunwind with respect
  Archie> to the above requirements? What is the minimum version of GCC
  Archie> required to generate acceptable DWARF2 information?

AFAIK, GCC 3.x or newer will be just fine.  2.9x may be OK too, but I
haven't tried myself.

  Archie> 3. Since JC has its own ELF loader, is it a fairly simple matter to
  Archie> hand the relevant debug section(s) over to libunwind for each
  Archie> function and have it magically do the right thing? Or do I need
  Archie> to parse them myself, etc? Would "table info format" be used here?

Normally, libunwind/x86 (for Linux) locates unwind info via
dl_iterate_phdr().  If that function doesn't see the stuff loaded by
your ELF loader, then yes, you'd have to register those tables via
_U_dyn_register() (and remove them via _U_dyn_cancel() before
unloading them).  Dynamic unwind info support isn't fully supported
yet on x86.  It's not difficult, it just hasn't been a priority so
far.  So if this becomes a show-stopper, let me know.

  Archie> 4. The build obviously fails on FreeBSD, which is one of my required
  Archie> platforms. I can handle porting work but how much stuff in
  Archie> libunwind is tryly Linux specific? E.g., it seems to depend on
  Archie> /proc interface, the "ptrace" interface (?), etc.

The main thing here is that we would need to add os-freebsd.c to do
the equivalent of what os-linux.c:tdep_get_elf_image() does.  To get
started, that function can just return NULL, in which case you won't
be able to obtain symbolic names for the code-addresses and
libunwind-ptrace won't work either.

The other areas that'd need porting:

 - A new file would need to be added to look up unwind info.  It would
   have to do the equivalent of dwarf/Gfind_proc_info-lsb.c.  The main
   dependency in that file is on having glibc's dl_iterate_phdr() and
   on using the GCC unwind-conventions.

 - ptrace/_UPT_reg_offset.c also would have to be updated eventually.
   Since you only do local unwinding, it's not strictly needed though.

  Archie> Which of these Linux-specific things are not needed for this
  Archie> application?

  Archie> 5. Any other gotchas, etc. regarding this idea? Will it work? :-)

It will work provided that you only unwind frames with proper unwind
info.  If code is compiled with -fexception, it will be fine, but
especially on x86, there may be a fair amount of hand-coded assembly
out there which doesn't have unwind-info.  Those are problematic, of
course.

        --david