Re: [libunwind] suggest adding unw_init_local_accessors

[Mark Young]

 I should have said... Consider pushing the dynamic unwind info list
lookup down inside the find_proc_info accessor function. Currently parser.c:get_proc_info
calls the find_proc_info accessor only if unw_find_dynamic_proc_info
comes up empty-handed. unw_find_dynamic_proc_info searches
the global _U_dyn_info_list only if the address space pointer matches unw_local_addr_space.
This means that the variation on the local address space that I
create to substitute my own access_mem function (for stack and backing store
address relocation) is treated as a remote address space with no dynamic
procedure lookup. Even if I chose to register them it would do no good. Moving
the dynamic procedure lookup responsibility into the find_proc_info accessor
could allow the libunwind user to opt in or out on a per-address-space basis,
eliminate unecessary calls to unw_find_dynamic_proc_info for address
spaces which do not have dynamic procedures, and eliminate the conditional
test to restrict the dynamic lookup to the local address space.

Our primary use for libunwind is to help implement our application's built-in
debugger, performance profiler, and crash backtrace features. We use external
tools like gdb in development, but the built-in tools take precedence for
our end users since they can relate to the source files in ways impossible
for external tools. Memory footprint is a major worry for us, so it is undesirable
to be required to duplicate data structures to enable the possible use of
a secondary set of less useful external tools. I'd rather have a choice.

Changing the subject, I have some other issues with address@hidden:

1) libunwind-dynamic.h needs to get installed.

2) to make unw_get_accessors(unw_local_addr_space) work
there needs to be a way to initialize unw_local_addr_space without calling
unw_init_local or unw_init_remote.

3) errors originating in ia64_make_proc_info can be returned by unw_init_local,
unw_init_remote, or unw_step. I'd like to focus recovery for this set of
errors in one place by deferring the call to ia64_make_proc_info
into unw_step. I believe this can be done with no change in functionality
by replacing the ia64_make_proc_info calls in common_init and update_frame_state
with return 0 and inserting the call to ia64_make_proc_info (and a test of
its return value) as the first thing done in unw_step.

--Mark


David Mosberger wrote:
> > > > > > On Fri, 06 Dec 2002 16:31:32 -0800, Mark Young <address@hidden> said:
> > > > > >           
> > > > >         
> > > >       
> > >     
> >   
>
>   Mark> Consider pushing the unwind info cache search and insertion
>   Mark> responsibility down inside the find_proc_info accessor
>   Mark> function.
>
> That's the way it works already.  Since I introduced the
> find_proc_info() callback, libunwind no longer caches unwind tables.
> It still caches unwind scripts, but only if the caching-policy allows
> it (by default, caching is turned on for local unwinding).
>
>   Mark> The address space creator could then choose an appropriate
>   Mark> policy, perhaps using utility routines exported by libunwind
>   Mark> to manage a cache if desired. In my case, since the dynamic
>   Mark> procedure address map and unwind info can be maintained
>   Mark> outside libunwind, I could define an address space and
>   Mark> find_proc_info accessor function to fill in the proc_info
>   Mark> structure for ip addresses in dynamic procedures. For other ip
>   Mark> addresses, I could simply call the find_proc_info function
>   Mark> associated with unw_local_addr_space and allow libunwind to
>   Mark> follow its default caching policy for non-dynamic procedures.
>
> It's fine if you want to do this for good performance, but for
> _correctness_ we also need a simple linked list of all dynamic
> procedures.  Otherwise, a debugger or a performance tool has no hope
> of being able to get a complete backtrace.  Note that the dynamic
> unwind list is purposely kept simple---lookup is relatively slow
> (O(N)), so that insertion and removal can be fast (O(1)).
>
> Wouldn't it be nice, e.g., if in gdb, you could do "bt" and get a
> complete backtrace including all the dynamically generated routines?
>
> 	--david

-- 
Mark Young            address@hidden     Tel: 503.526.1661
Staff Engineer         www.model.com      Fax: 503.526.5473
Model Technology, Inc.
10450 SW Nimbus Avenue/Bldg RB, Portland, OR 97223-4347 USA