Re: [Libunwind-devel] Local unwind problem on ia64

[Curt Wohlgemuth]

Hi David:

> Are you mixing static libunwind-ia64.a with shared libunwind.so?

No.  Oops, my link line below should have been:

             g++ <.o files> ... libunwind-ia64.a libunwind.a ...

> In any case, here is the reason for declaring the reference weak:

>     Make all references from libunwind-ia64 to libunwind weak such that
>     it's possible to link against libunwind-ia64.a without needing
>     libunwind.a.

But the weak unsat for _Uelf64_get_proc_name in Ginit.o is in
libunwind-ia64.a, and the def that would/should satisfy it is in elf64.o,
_also_ in libunwind-ia64.a.  So why the weak attribute??

(I previously thought that the problem was both because of the weak unsat,
and the hidden def.  It seems the latter is unimportant; even if
_Uelf64_get_proc_name is not hidden, the weak unsat won't pull in elf64.o
from the library.  Argh...)

Thanks,
Curt


>     BKrev: 419a4b4bYWEKA80IEowZKmzBEMLkGA
> 
> commit 4e731a55729a25ef0e50f4f2aaa1bd95e4eec89e
> Author: hp.com!davidm <hp.com!davidm>
> Date:   Tue Nov 16 18:47:39 2004 +0000
> 
>     (get_dyn_info_list_addr): When compiling into libunwind-ia64, declare
>         _U_dyn_info_list_addr as weak and fail if the symbol remained
>         undefined.
>     (get_static_proc_name): Likewise for _Uelf64_get_proc_name().
> 
> If indeed you're mixing static and shared objects, I'm not sure that can work.
> 
>   --david
> 
> 
> On 11/6/07, Curt Wohlgemuth <address@hidden> wrote:
> > Hi:
> >
> > The app I'm using with libunwind uses the library for both remote and local
> > unwinding.  I've found what appears to be a bug on ia64 in such a
> > circumstance.
> >
> > The problem shows up when the app tries to create a stack trace for itself:
> > the IP values shown are correct, but no procedure names are shown.  I've
> > narrowed the problem down to src/ia64/Ginit.c, in the routine
> > get_static_proc_name().  The issue is with the pragma on line 352:
> >
> >
> >       static int
> >       get_static_proc_name (unw_addr_space_t as, unw_word_t ip,
> >                             char *buf, size_t buf_len, unw_word_t *offp,
> >                             void *arg)
> >       {
> >       #ifndef _UNW_LOCAL_ONLY
> >    => # pragma weak _Uelf64_get_proc_name
> >         if (!_Uelf64_get_proc_name)
> >           return -UNW_EINVAL;
> >       #endif
> >         return _Uelf64_get_proc_name (as, getpid (), ip, buf, buf_len, 
> > offp);
> >       }
> >
> >
> > Here's the problem:
> >
> >    - Link line like
> >
> >                 g++ <.o files> ... libunwind-ia64.a libunwind ...
> >
> >    - The object libunwind-ia64.a::Ginit.o is pulled in, and has a weak unsat
> >      for _Uelf64_get_proc_name
> >
> >    - The object libunwind-ia64.a::elf64.o has a hidden def for the symbol
> >      above
> >
> >    - Apparently, gcc 3.3.3 doesn't bother pulling in a hidden def to satisfy
> >      a weak unsat => _Uelf64_get_proc_name() remains unsatisfied in the
> >      final binary.  Thus it never gets called, and the above routine always
> >      returns -UNW_EINVAL.
> >
> >      I've confirmed this with a simple example.
> >
> > This problem wouldn't show up if I were using the library for local
> > unwinding only, with _UNW_LOCAL_ONLY defined.  Only if I'm using it for both
> > local and remote unwinding, and, in the case of local unwinding, just
> > calling unw_init_local() (i.e., not using my own accessor functions).
> >
> > David, what is the point of the weak pragma above?  Why would the above
> > routine be used, without also using the Elf function
> > _Uelf64_get_proc_name()?  Is there something else I should be doing instead?
> >
> > Attached is a simple patch that removes the pragma, if you think that it's
> > not needed.
> >
> > Thanks,
> > Curt
> >
> > _______________________________________________
> > Libunwind-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/libunwind-devel
> >
> >
> >
> 
> 
> -- 
> Mosberger Consulting LLC, http://www.mosberger-consulting.com/
>