Re: [Libunwind-devel] x86-64 libunwind status?

[Curt Wohlgemuth]

Hi Arun:

(I tried to send this once already, but got hit by the 40K size limit.
Resending with a gzip'ed tar file, and hoping it gets through.)

Thanks for getting back to me.

> I generally test the "local unwinding" (in-process unwinding) functionality
> regularly for http://code.google.com/p/google-perftools/.
> Will look into your report when I get a chance.
> 
> Could you also build with --enable-debug and send a trace with
> UNW_DEBUG_LEVEL=x where x is the level you think has the right level of
> debug info?

I'm attaching "traces.tar.gz" which contains:

        sleep-2.out : stdout from "test-ptrace -v sleep 1"
        dbg-2.out   : stderr from above, where UNW_DEBUG_LEVEL is set to 2.

(The only difference between a debug level of 1, or > 1, is the return value
from "_Ux86_64_step", but I'm including it anyway.)

As you can see, for the "good" stack traces in the output, the debug traces
are quite straightforward:

    >_Ux86_64_init_remote: (cursor=0x7fff9964e160)
    >_Ux86_64_step: (cursor=0x7fff9964e160, ip=0x00002ba2309b3639)
     >_Ux86_64_step: returning 1
    >_Ux86_64_step: (cursor=0x7fff9964e160, ip=0x00002ba2309b2666)
     >_Ux86_64_step: returning 1
    >_Ux86_64_step: (cursor=0x7fff9964e160, ip=0x00002ba2309a5479)
     >_Ux86_64_step: returning 1
    >_Ux86_64_step: (cursor=0x7fff9964e160, ip=0x00002ba2309a4cf8)
     >_Ux86_64_step: returning 0
    >_Ux86_64_init_remote: (cursor=0x7fff9964e160)
    ...

At the point where the stack traces no longer specify any function names,
the debug trace starts to look like this:

    >_Ux86_64_init_remote: (cursor=0x7fff9964e160)
    >_Ux86_64_step: (cursor=0x7fff9964e160, ip=0x00002ba230d41b33)
    >_Ux86_64_step: [RBP=0x6] = 0x7fff7a101ef0 (cfa = 0x7fff7a101e10)
    >_Ux86_64_step: Frame Chain [RIP=0x7fff7a101ef8] = 0x2ba230d416f6
     >_Ux86_64_step: returning 1
    >_Ux86_64_step: (cursor=0x7fff9964e160, ip=0x00002ba230d416f6)
    >_Ux86_64_step: [RBP=0x7fff7a101ef0] = 0x7fff7a101fb0 (cfa = 0x7fff7a101e20)
    >_Ux86_64_step: Frame Chain [RIP=0x7fff7a101fb8] = 0x2ba230d40e34
     >_Ux86_64_step: returning 1
    ...

You can also see, in the stdout, an IP value of 0x2ba230d41b33 appears 4
times at stack tops, associated with "_nl_load_locale+0xf3", before the
stack traces turn "bad" with this same IP.

I ran "sleep 2" and attached to it with gdb, and was able to get a valid
stack trace in it:

   #0  0x00002b962929cb42 in __nanosleep_nocancel () from /lib64/tls/libc.so.6
   #1  0x0000000000402923 in xnanosleep ()
   #2  0x00000000004012f2 in main ()

I don't know what my gdb is using for unwind, but it seems to do okay.

Related to this, and exposing my ignorance of the architecture, I'm confused
by register values returned by gdb during the attach case above.  The value
of "$rbp" is 0x7ffff9f3bf40; the value of "$fp" is 0x7ffff9f3bf00.  I
thought that RBP holds the frame pointer; what would "$fp" be then, and why
would it be different?  The value at address "$fp + 0x8" is actually the
return address I'm expecting (0x402923).

Thanks,
Curt

traces.tar.gz
Description: application/gunzip