Messages in this thread | | | Date | Mon, 08 Aug 2005 22:27:10 +0200 | From | Petr Vandrovec <> | Subject | Re: x86_64 frame pointer via thread context |
| |
Dave Jiang wrote: > Petr Vandrovec wrote: > >> Dave Jiang wrote: >> >>> Andi Kleen wrote: >>> >>>> Dave Jiang <djiang@mvista.com> writes: >>>> >>>>> Am I doing something wrong, or is this intended to be this way on >>>>> x86_64, or is something incorrect in the kernel? This method works >>>>> fine on i386. Thanks for any help! >>>> >>>> >>>> >>>> >>>> >>>> I just tested your program on SLES9 with updated kernel and RBP >>>> looks correct to me. Probably something is wrong with your user space >>>> includes or your compiler. >>>> >>>> -Andi >>> >>> >>> >>> >>> I revised the app a little so that it would allow the threads to >>> start, thus should prevent rBP w/ all 0's showing up. Below are some >>> of results that I've gotten from various different distros and >>> platforms. As you can see, the f's shows up on most of them, >>> including Suse 9.2. The only one showed up looking ok is the >>> Mandrake/Mandriva distro. I'm not sure how different SLES9 is from >>> Suse9.2.... >> >> >> >> Replace call to sleep() with busy loop. Glibc's sleep() uses %ebp for >> its own data, so when you interrupt sleep(), you get rbp=(unsigned >> int)-1, >> as rbp really contains 0x0000.0000.ffff.ffff when nanosleep() syscall >> is issued. >> Petr >> > > From what I understand, when you signal a thread, the signal handler > executes in the thread context and not the main process context. So > therefore the rbp would be the thread's copy and not the one that > sleep() just modified. So whatever sleep does to the main process > context, there shouldn't be any effect on the thread context.... Also, > what can I call to allow the threads to run? sleep() allows me to run > the other threads. Busy wait does not.....
I do not understand. You call sleep() from both threads you spawn (as well from main), so both threads are always interrupted in the sleep(2). Load your process to the debugger...
#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
Petr
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |