Re: [libunwind] [RFD] supporting dynamically generated code

[Robert Cohn]

I would like to have a an api that supports unwinding for dynamically
generated code.

I don't mind the extra overhead for (1) as long as adding information for
new code is a constant time operation. I was concerned that the unwind info
for dynamically generated code would have to sorted by code address and
adding new information for new code would be O(n).

----- Original Message -----
From: "David Mosberger" <address@hidden>
To: <address@hidden>
Sent: Tuesday, November 19, 2002 2:27 PM
Subject: [libunwind] [RFD] supporting dynamically generated code


> 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
> _______________________________________________
> libunwind mailing list
> address@hidden
> http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/libunwind
>