Dave Jiang wrote:
Petr Vandrovec wrote:
#0 tb_sig_handler (sig=33, info=0x407ff2f0, ucontext=0x407ff1c0) at
ttest1.c:26
#1 <signal handler called>
#2 0x00002aaaaad81335 in nanosleep () from /lib/libc.so.6
#3 0x00002aaaaad811a5 in sleep () from /lib/libc.so.6
#4 0x0000000000400871 in test_thread1 (arg=0x0) at ttest1.c:40
#5 0x00002aaaaabc6b55 in start_thread () from /lib/libpthread.so.0
#6 0x00002aaaaada87f0 in clone () from /lib/libc.so.6
Ooops, you are right. I forgot about those ones in the threads. Yes you
are right. Once the sleep goes away rBP displays the correct values. Is
this issue due to glibc or because of the toolchain? I do not have this
issues on 32bit x86.... I would assume that the reason it works on
Mandrake is due to the toolchain they use versus other distros? The
toolchain determines which registers to use and the
-fno-omit-frame-pointer did not prevent some of them from clobbering rbp?
You are building only your application with -fno-omit-frame-pointer,
libraries you are using are just used as is. On 32bit x86 it works
as -O2 on x86 does not imply -fomit-frame-pointer, as frame pointer
is required (well, was) for debugging. On x86-64 frame pointer is
not needed for debugging as it was always using DWARF debug info,
and so -O2 on x86-64 implies -fomit-frame-pointer. Due to this most
of libraries you'll find on your 64bit system are built without frame
pointer. Mandrake either explicitly asks for -fno-omit-frame-pointer,
or maybe their glibc is just sufficiently different that their sleep()
does not need %rbp for sleep().
Loading their glibc to the debugger and inspecting sleep & nanosleep
will reveal whether %rbp is just unchanged by these (and so it works
due to luck), or whether their sleep uses pushq %rbp; movq %rsp,%rbp
- in which case they built glibc with frame pointers for no apparent
reason.
You must use debugging informations to get stacktrace on x86-64.
Blindly following %rbp does not work on this architecture (and lot
of others).
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |