[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libunwind] Some basic questions about libunwind

From: Archie Cobbs
Subject: [libunwind] Some basic questions about libunwind
Date: Sat, 20 Nov 2004 21:22:01 -0600 (CST)


I'm looking at the possibility of using libunwind for JC, a Java
VM implementation (, and have some basic
questions, as I'm still a bit unsure about how it would all work.

Brief summary: JC can be thought of as a JVM with a "way ahead of
time" compiler for Java bytecode, where the compiled code for each
class is stored in the filesystem as regular ELF objects (".o"
files).  These ELF objects are normal files created by GCC, created
from computer-generated C source files. JC includes its own ELF loader
to load these files at runtime. Right now JC runs only on x86 and on
FreeBSD and Linux.

Use of libunwind in JC would be limited strictly to:

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

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

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

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

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

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

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

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

4. The build obviously fails on FreeBSD, which is one of my required
   platforms. I can handle porting work but how much stuff in
   libunwind is tryly Linux specific? E.g., it seems to depend on
   /proc interface, the "ptrace" interface (?), etc. Which of these
   Linux-specific things are not needed for this application?

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


Archie Cobbs      *        CTO, Awarix        *

reply via email to

[Prev in Thread] Current Thread [Next in Thread]