Re: [libunwind] A few questions and observations

[David Mosberger]

>>>>> On Thu, 31 Oct 2002 13:28:43 -0500, Robert Faught <address@hidden> said:

  Robert> 1. The unwind info is found by searching on the ip. This
  Robert> works in the local case, where there is only one process in
  Robert> question. In the remote case (a debugger, for example),
  Robert> multiple processes may be active simultaneously and may have
  Robert> limited lifetimes.

  Robert> [snip]

  Robert> But finally came to the conclusion that caching
  Robert> the info was best handled by our own library tables. These
  Robert> already go through a lot of trouble to decide when libraries
  Robert> are identical or changed. I believe I will disable the info
  Robert> table and always force the cb_acquire_unwind_info callback.

  Robert> I am gassing on about this because I think it is a general
  Robert> problem with remote use rather than with our application.

Yeah, I can see why you'd want that.

  Robert> Can you think of other places in the code where the global
  Robert> state assumes a single process?

Well, there is the unwind script cache, which is also indexed by IP.
I clearly would like to be able to support multi-process debugging.  A
relatively easy way to do that would be to have a way to completely
disable caching.  You probably want that for debugging anyhow, because
the lookup-performance is trivial compared to what else is going on on
a debugger.  In the latest sources, I added a new routine
unw_set_caching_policy() which will allow you to disable caching.
It's also likely that I'll revise the call-back interface
(acquire_info/release_info), partly to make it easier to support
unwinding past dynamically generated code.  I haven't thought through
this completely yet, so expect these areas to change some more.

  Robert> 2. Is there something special about BR6? I think it should
  Robert> be handled like BR7 (another scratch register) but it is
  Robert> missing from the switch statements in ia64_scratch_loc and
  Robert> ia64_access_regs in reg.c. (Also missing from
  Robert> unw_get_save_loc.)

Good catch.  That was a typo which got cut & paste several times.  I
hope to have fixed the offenders in my tree, now.

  Robert> 3. At line 129 in unw_get_save_loc.c

  Robert> memset (sloc, 0, sizeof (sloc));
  Robert>
  Robert> if (!sloc)
  Robert>   {
  Robert>     sloc-> type = UNW_SLT_NONE;
  Robert>     return 0;
  Robert>   }

  Robert> This looks funny to me but I have not had a problem with it.

That does look pretty non-sensical, doesn't it? ;-)

It should have said:

  memset (sloc, 0, sizeof (sloc));

  if (!loc)
    {
      sloc->type = UNW_SLT_NONE;
      return 0;
    }

I fixed that now in my tree.  Thanks for pointing this out.

  Robert> 4. The building and using the library was very easy and I
  Robert> want to thank you for making it available.

Glad to hear that!

  Robert> The main difficulty I had setting it up for remote use was
  Robert> that, after taking a trap, bsp (read by ptrace) points to
  Robert> the next register frame rather than the current
  Robert> one. Subtracting the frame size from bsp (before the
  Robert> callback returns it) fixed the problem.  This might be worth
  Robert> a note in the readme.

Good point.  I added a comment on this near the end of doc/NOTES.

Obviously the entire documentation needs to be much improved.  I hope
to be starting to address this in the not too distant feature.

        --david