[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libunwind] A few questions and observations
From: |
Robert Faught |
Subject: |
Re: [libunwind] A few questions and observations |
Date: |
Thu, 31 Oct 2002 13:28:43 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 |
[I'm re-sending this message to the libunwind list with Rob's permission;
that way, we can discuss his points in the open.]
Hello David,
I have linked libunwind into our debugger and it is working well. There
are, however, a few issues that I want to bring to your attention.
Rob Faught
1. The unwind info is found by searching on the ip. This works in the
local case, where there is only one process in question. In the remote
case (a debugger, for example), multiple processes may be active
simultaneously and may have limited lifetimes. Often libraries are
shared by more than one process and sometimes libraries with the same
names are different across target machines (due to version skew in
system libs, for example).
How to solve this problem? I first thought that I would use the context
pointer (the last arg in the callbacks) to index the unwind info. This
would work but would explode the table, since the context is really a
thread id.
I then thought about adding the process id to the table indexing. But
finally came to the conclusion that caching the info was best handled by
our own library tables. These already go through a lot of trouble to
decide when libraries are identical or changed. I believe I will disable
the info table and always force the cb_acquire_unwind_info callback.
I am gassing on about this because I think it is a general problem with
remote use rather than with our application.
Can you think of other places in the code where the global state assumes
a single process?
2. Is there something special about BR6? I think it should be handled
like BR7 (another scratch register) but it is missing from the switch
statements in ia64_scratch_loc and ia64_access_regs in reg.c. (Also
missing from unw_get_save_loc.)
3. At line 129 in unw_get_save_loc.c
memset (sloc, 0, sizeof (sloc));
if (!sloc)
{
sloc->type = UNW_SLT_NONE;
return 0;
}
This looks funny to me but I have not had a problem with it.
Perhaps:
if (!sloc)
return 0;
memset (sloc, 0, sizeof (sloc));
4. The building and using the library was very easy and I want to thank
you for making it available. The main difficulty I had setting it up for
remote use was that, after taking a trap, bsp (read by ptrace) points to
the next register frame rather than the current one. Subtracting the
frame size from bsp (before the callback returns it) fixed the problem.
This might be worth a note in the readme.
David Mosberger wrote:
Robert> I grabbed a copy of libunwind from unwind.bkbits.net
Robert> yesterday. I am having trouble with autoconf and
Robert> configure. Before I start mucking around, I'd like to know
Robert> which version of autoconf is known to work.
Robert> With autoconf 2.13 I get:
Robert> autoconf: Undefined macros:
Robert> configure.in:53 AC_CONFIG_LINKS
Robert> With autoconf 2.54, configure complains:
Robert> "error: cannot find input file: Makefile.in"
You need at least autoconf 2.53 (I think; I'm using 2.54 now) and
you also need automake v1.5 or newer.
However, since these versions are kind of cutting edge, I decided to
check the necessary files into bitkeeper. I haven't tested it yet,
but in theory you should be able pull on the bitkeeper repository and
then run "configure" directly (without autoconf/automake).
--david
_______________________________________________
libunwind mailing list
address@hidden
http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/libunwind
- Re: [libunwind] A few questions and observations,
Robert Faught <=