libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] suggest adding unw_init_local_accessors


From: David Mosberger
Subject: Re: [libunwind] suggest adding unw_init_local_accessors
Date: Mon, 9 Dec 2002 14:07:15 -0800

>>>>> On Mon, 09 Dec 2002 13:52:59 -0800, Mark Young <address@hidden> said:

  Mark>   I should have said... Consider pushing the dynamic unwind
  Mark> info list lookup down inside the find_proc_info accessor
  Mark> function. Currently parser.c:get_proc_info calls the
  Mark> find_proc_info accessor only if unw_find_dynamic_proc_info
  Mark> comes up empty-handed.  unw_find_dynamic_proc_info searches
  Mark> the global _U_dyn_info_list only if the address space pointer
  Mark> matches unw_local_addr_space. This means that the variation on
  Mark> the local address space that I create to substitute my own
  Mark> access_mem function (for stack and backing store address
  Mark> relocation) is treated as a remote address space with no
  Mark> dynamic procedure lookup.

Oh, that's only a temporary limitation: I haven't had time to
implement the remote-case for dynamic procedure lookup yet.  Actually,
I have prototype code, but it's not finished yet and completely
untested.  But over the next couple of days, it will get fixed.

Sorry, if this wasn't clear.

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

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

Yes, thanks for pointing that out (please do keep in mind that this is
very much bleeding edge stuff; I do try to work on it as much as
possible, but I can't do everything at once).

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

unw_local_addr_space gets initialized automatically.  If not, there is
a bug somewhere (hmmh, come to think of it, I think
unw_get_accessors() should check whether initialization has been done
already and, if not, do it).

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

That's probably OK.  I'll look into making this change.

Thanks,

        --david


reply via email to

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