Hi, Nicolas:
Nicolas Williams wrote:
> On Wed, Dec 17, 2008 at 10:53:28PM +0800, Jason Zhao wrote:
>
>> I have a quick question, I run the following dtrace command on my Lenovo
>> T61 which is 64-bit kernel running.
>> But after that, I found the dtrace return 32-bit address, otherthan
>> 64-bit address, why does that happen?
>> Does that mean 64-bit kernel still use 32-bit syscall?
>>
>
> No, 32-bit user processes run in 32-bit mode. A 64-bit platform running
> a 64-bit kernel can run both, 32- and 64-bit user processes.
>
> What's happening is that you're catching the *entry* to exece(), and
> that's from your shell (after fork()ing the child that is to run ls(1)):
>
>
>> # dtrace -n 'syscall::exece:entry { stack(); ustack() }'
>>
> ^^^^^
>
>> dtrace: description 'syscall::exece:entry ' matched 1 probe <--- run
>> "/usr/bin/amd64/ls" command on other term.
>> CPU ID FUNCTION:NAME
>> 1 59502 exece:entry
>> unix`_sys_sysenter_post_swapgs+0x14b
>>
>> 0xfedb0b85 <------------- 32-bit address
>>
>
> exece() normally does not return to the caller (it returns only if
> there's an error), and ls(1) doesn't call exece(). What are you looking
> for?
>
I am just giving it a try for dtrace to probe syscall. Because I am
curious how dtrace probe the syscall. On sys_sysenter, I could not
find the probe dtrace put on.
What does it mean "ls(1) doesn't call exece()"? Then how the ls(1)
call the syscall to execute?
Thanks
Jason
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
