libunwind-devel
[Top][All Lists]
Advanced

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

[Libunwind-devel] Local unwind problem on ia64


From: Curt Wohlgemuth
Subject: [Libunwind-devel] Local unwind problem on ia64
Date: Tue, 6 Nov 2007 09:23:58 -0800
User-agent: Mutt/1.5.6i

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

Attachment: patch-file
Description: Text document


reply via email to

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