[Libunwind-devel] x86-64 libunwind status?

[Curt Wohlgemuth]

Hi:

I'm new to this mailing list; my apologies if this should be obvious to me,
but I didn't see anything about it in the last several months in the
archive, and the README isn't totally clear on this.

I'm using v 0.99 of libunwind, building for remote unwinding on x86-64.  I'm
using

        tests/test-ptrace

as an example of the use of remote unwinding, and I'm seeing some unexpected
results with it.  What is the general state of unwinding on x86-64?  Is this
mostly dependent on the unwind information in binaries, or the version of
the compiler/linker used to build the binaries?

For example, running

        test-ptrace -v /bin/sleep 1

shows nice stack frames on my system until I start to get stack frames with
no mention of a function at the top of the stack:

   ================

   00002b67993f0b33 +0x2a                            (sp=00007fff11a55770)
           proc=00002b67993f0b33-00002b67993f0b34
           handler=0 lsda=0
   00002b67993f06f6 +0x2a                            (sp=00007fff11a55780)
           proc=00002b67993f06f6-00002b67993f06f7
           handler=0 lsda=0
   00002b67993efe34 +0x2a                            (sp=00007fff11a55790)
           proc=00002b67993efe34-00002b67993efe35
           handler=0 lsda=0
   0000000000401228 main+0x38                        (sp=00007fff11a557a0)
           proc=00000000004011f0-0000000000401476
           handler=0 lsda=0
   000000004288a954 +0x38                            (sp=00007fff11a55800)
           proc=000000004288a954-000000004288a955
           handler=0 lsda=0
   ================
   ...

At this point forward, no stack entry has a valid function name except for
"main+0x38" above.  I never see a stack frame with the string "sleep" (or
"nanosleep," which I'm expecting) in the output.  The test does not fail.

My simple a.out which calls nanosleep() works fine, under 'test-ptrace.'

I see that 'run-ptrace-misc' is expected to fail on x86-64; are my results
the same issue as this one (the gcc.gnu.org bugs listed)?

My kernel is 2.6.22; my gcc is 3.3.3.  My libc's "--version" output shows

   GNU C Library stable release version 2.3.3

which is pretty old.

Thanks,
Curt

p.s.  FWIW, the end of the README still has the old, non-existent

        address@hidden

mailing list specified for the developer contact.