libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Mosberger-Tang
Subject: Re: [Libunwind-devel] Local unwind problem on ia64
Date: Tue, 6 Nov 2007 16:21:00 -0700

Curt,

Are you mixing static libunwind-ia64.a with shared libunwind.so?  In
any case, here is the reason for declaring the reference weak:

commit 14524c439f758f79d0ebbde44c969290c0bf3d39
Author: hp.com!davidm <hp.com!davidm>
Date:   Tue Nov 16 18:47:39 2004 +0000

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

    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/




reply via email to

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