libunwind-devel
[Top][All Lists]
Advanced

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

[libunwind] [RFD] supporting dynamically generated code


From: David Mosberger
Subject: [libunwind] [RFD] supporting dynamically generated code
Date: Tue, 19 Nov 2002 11:27:51 -0800

As most of you know, one important feature that's currently missing
from libunwind is support for dynamically generated code.  From my
perspective, the biggest issue here is when the unwind info for the
dynamically generated code is created and where the unwind info lives.

Consider the case of a process A unwinding the stack of a process B (A
might be a debugger, for example).  There are basically two
approaches:

  (1) When the dynamic code gets generated in B, we can register the
      associated unwind info along with the new code (i.e., the unwind
      info would live in B's address space).

or

  (2) No unwind info is generated with the dynamic code, instead,
      process A needs some (magic) way to detect when it's dealing
      with the stack-frame of a dynamically generated function and to
      determine the save-locations of the preserved registers.

The "magic" info required to make (2) work could be supplied by a
shared library "plug-in" (this is an idea I first heard proposed by
Cary Coutant).  For example, with a Java JIT compiler from Sun, you
might have libunwind-plugin-sun-jvm.so and this library would provide
a "probe" routine to detect whether a given frame is a Java JIT frame
and other routines to recover the saved state from the frame.

Compared to (1), the advantages of (2) are that there is no
unwind-related overhead at the time the code is generated.  It also
might have a slight flexibility advantage in accommodating extremely
weird case, such as where a call frame is constructed dynamically in
B, but the saved state actually lives in A (this is what roughly
happens with gdb "inferior calls", though there is other ways of
handling this situation).

On the other hand, getting (2) to work reliably in practice could be
quite challenging.  Even within the same platform, you'd have to
ensure that all plugin libraries needed by a particular program are
installed and available to libunwind.  I think this could get tricky
especially when considering that many of the JIT-like tools may be
proprietary.  For example, I'm not sure how we'd go about convincing a
JIT vendor to produce up-to-date and correct libunwind plugins
(especially considering that over time there would presumably have to
be multiple versions of the plugin, to accommodate different versions
of the JIT).  For cross-platform unwinding, it would be even more
challenging and, IMHO, completely impractical unless we could somehow
ensure that all libunwind-plugins are open source (again, that could
be a tough sell with proprietary JIT vendors, for example).

Having said that, I'm not sure as to what the willingness is to incur
(slightly) higher overhead for dynamic code generation as required by
(1).  Hopefully, the overhead could be kept minimal with a
intelligently designed registration interface, but clearly it would
entail a bit more work at dynamic-code generation time.

Since I'm not a JIT expert etc., I'd really be interested in the
views, opinions, and experiences of others on this list.

        --david


reply via email to

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