Re: [libunwind] A few questions and observations

[Robert Faught]

[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