Re: x86_64 frame pointer via thread context

[Dave Jiang]

Petr Vandrovec wrote:
> Dave Jiang wrote:
>
> > Andi Kleen wrote:
> >
> > > Dave Jiang <djiang@xxxxxxxxxx> 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.....

--
Dave

------------------------------------------------------
Dave Jiang
Software Engineer          Phone: (480) 517-0372
MontaVista Software, Inc.    Fax: (480) 517-0262
2141 E Broadway Rd, St 108   Web: www.mvista.com
Tempe, AZ  85282          mailto:djiang@xxxxxxxxxx
------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/