[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libunwind] A few questions and observations
From: |
David Mosberger |
Subject: |
Re: [libunwind] A few questions and observations |
Date: |
Mon, 11 Nov 2002 17:00:14 -0800 |
>>>>> 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