From: Dave Jiang <djiang@mvista.com>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Andi Kleen <ak@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: x86_64 frame pointer via thread context
Date: Mon, 08 Aug 2005 13:19:22 -0700 [thread overview]
Message-ID: <42F7BE4A.6030709@mvista.com> (raw)
In-Reply-To: <42F7BB2C.6070004@vc.cvut.cz>
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.....
--
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@mvista.com
------------------------------------------------------
next prev parent reply other threads:[~2005-08-08 20:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <42F3EC97.2060906@mvista.com.suse.lists.linux.kernel>
2005-08-06 11:54 ` x86_64 frame pointer via thread context Andi Kleen
2005-08-08 7:13 ` Jan Engelhardt
2005-08-08 17:27 ` Dave Jiang
2005-08-08 17:35 ` Dave Jiang
2005-08-08 18:35 ` Dave Jiang
2005-08-08 20:06 ` Petr Vandrovec
2005-08-08 20:19 ` Dave Jiang [this message]
2005-08-08 20:27 ` Petr Vandrovec
2005-08-08 21:09 ` Dave Jiang
2005-08-08 22:29 ` Petr Vandrovec
2005-08-05 22:47 Dave Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42F7BE4A.6030709@mvista.com \
--to=djiang@mvista.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vandrove@vc.cvut.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox