[libunwind] RE: Question on libunwind-dynamic

[Thomas Hallgren]

>   Thomas> 2. Using the libunwind-dynamic, there is a way to register
>   Thomas> things so that libunwind is globally aware of them. Would it
>   Thomas> be possible to do the same thing for an accessors?
> 
> I'm not sure what you have in mind here.  The only suggestion I have
> seen is to provide a dynamically-loaded extension to libunwind, but I
> doubt this is a feasible solution.  I'm worried that ISVs would create
> binary-only extensions to libunwind, which would make it impossible
> to, e.g., unwind a particular stack from a platform which isn't
> supported by the ISV.  Even when the extensions are available for the
> local platform, just managing them would be a huge pain, in my
> opinion.
> 
I thought of something better that merges the _U_dyn_register approach
with the approach using accessors.

As you know, I'm trying to merge libunwind with the JRockit Java VM. We
(and I guess mosts VM's) already have structures describing the code
blocks that we generate. We also have optimized functions to find those
structures given a certain IP.

The dynamic registration routine could be changed so that it is
performed in two steps. The first step would register a set of function
pointers representing all the functions needed for libunwind to extract
whatever info it needs. The second would replace the current
_U_dyn_register call and instead of registering a unw_dyn_info_t just
register a "class" (return value from step 1) and an opaque pointer.

Something like this:

unw_proc_class_t pc;

/* For each type of procedure that you have (typically
 * very few, 1 or so).
 */
pc = _U_dyn_register_proc_class(<func pointers>);

/* For all generated procedures
 */
_U_dyn_register(pc, <opaque data struct>);

In other words, encapsulate the unw_dyn_info_t. Since both the function
table and the structures will be present in a core file, it should be
possible to unwind it.

Regards,

Thomas Hallgren