Re: [libunwind] Some basic questions about libunwind

[Archie Cobbs]

David Mosberger wrote:
>>>>>>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?

That's a good question.. I haven't done any serious comparison but a few
quick tests show that JC is still slower but not dramatically so. One
of the main contributors is the way references on the stack must be
explicitly accounted for.. hopefully using libunwind would help this.
Of course using standard setjmp() for try .. catch doesn't help either.

>   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.)

Up until now JC has had a non-conservative (liberal? :-) GC, i.e., it
expects all references to be "real" references. However, that's not a
hard restriction to relax, and doing so would make this approach viable.

It didn't occur to me before but you're probably right that considering
the entire stack would probably be faster overall.

Of course it's still necessary to crawl the stack for constructing
exception stack traces (JC knows how to map PC addresses to original
Java method and source code line numbers).

>   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.

Great.. specifically, what work remains?

>   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.

I'm already loading and relocating all the sections myself, so ideally
what I'd prefer to do is just say "Here libunwind, this is the .debug_foo
section"... i.e., if libunwind already knows how to parse DWARF2 then
it would be nice to reuse that capability. Would that require new
libunwind API functions?

>   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.

It seems like maybe there ought to be an additional API inserted
in there somewhere. I.e., there seem to be assumptions about the
runtime environment. Instead, perhaps there could be a "runtime API"
defined such that normally the default implementation would be used
but the application could also choose to provide its own. Then each
O/S could have its own default implementation (Linux, FreeBSD, etc.)

Not really understanding the code yet, this is just fuzzy speculation.

>   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.

Not a problem for JC, because all these objects comes from
the generated C files.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.
*