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