[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: 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.


  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
 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> With autoconf 2.54, configure complains:
 Robert> "error: cannot find input file:"

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).

libunwind mailing list

reply via email to

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