dtrace discuss - Dec 2008 - [Fwd: Why exece syscall on 64-bit OS returns 32-bit address]

-------------- next part --------------
An embedded message was scrubbed...
From: Jason Zhao <Jason.Zhao at Sun.COM>
Subject: Why exece syscall on 64-bit OS returns 32-bit address
Date: Wed, 17 Dec 2008 22:48:54 +0800
Size: 1320
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20081217/c26069e7/attachment.nws>

Hi Jason,

It would appear that your shell is a 32-bit process and you''re  
recording the stack on entry to exece rather than the return. That is  
to say, you''re recording the stack of your shell rather than the stack
of the 64-bit ls process:

# dtrace -n ''syscall::exece:return{ stack(); ustack();
}''dtrace:
description ''syscall::exece:return'' matched 1 probe
CPU     ID                    FUNCTION:NAME
   1  82155                     exece:return
               unix`sys_syscall32+0x1fc

               0xfffffd7fff3bd8da

Adam

On Dec 17, 2008, at 6:53 AM, Jason Zhao wrote:
>
>
> From: Jason Zhao <Jason.Zhao at Sun.COM>
> Date: December 17, 2008 6:48:54 AM PST
> To: dtrace-discuss at opensolaris.org
> Subject: Why exece syscall on 64-bit OS returns 32-bit address
>
>
> Hi, All
>
> 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?
>
> # isainfo -v
> 64-bit amd64 applications
> ssse3 cx16 mon sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
> 32-bit i386 applications
> ssse3 ahf cx16 mon sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
>
>
> # 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
> 0x80810f8
> 0x808038e
> 0x807d1ed
> 0x807cb6f
> 0x80710c2
> 0x806f566
> 0x806ee4e
>
>
> Thanks
> Jason
>
>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Thank you, Adam

Adam Leventhal wrote:
> Hi Jason,
>
> It would appear that your shell is a 32-bit process and you''re 
> recording the stack on entry to exece rather than the return. That is 
> to say, you''re recording the stack of your shell rather than the
stack
> of the 64-bit ls process:
>
> # dtrace -n ''syscall::exece:return{ stack(); ustack();
}''dtrace:
> description ''syscall::exece:return'' matched 1 probe
> CPU     ID                    FUNCTION:NAME
>   1  82155                     exece:return
>               unix`sys_syscall32+0x1fc
>
>               0xfffffd7fff3bd8da
Yes, my shell is 32-bit, as following:

# file /usr/bin/bash
/usr/bin/bash:    ELF 32-bit LSB executable 80386 Version 1 [FPU], 
dynamically linked, stripped

In other words, I should have run 64-bit bash other than 32-bit one. So 
that I could get 64-bit address.

Thanks
Jason
>
> Adam
>
> On Dec 17, 2008, at 6:53 AM, Jason Zhao wrote:
>
>>
>>
>> From: Jason Zhao <Jason.Zhao at Sun.COM>
>> Date: December 17, 2008 6:48:54 AM PST
>> To: dtrace-discuss at opensolaris.org
>> Subject: Why exece syscall on 64-bit OS returns 32-bit address
>>
>>
>> Hi, All
>>
>> 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?
>>
>> # isainfo -v
>> 64-bit amd64 applications
>> ssse3 cx16 mon sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
>> 32-bit i386 applications
>> ssse3 ahf cx16 mon sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
>>
>>
>> # 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
>> 0x80810f8
>> 0x808038e
>> 0x807d1ed
>> 0x807cb6f
>> 0x80710c2
>> 0x806f566
>> 0x806ee4e
>>
>>
>> Thanks
>> Jason
>>
>>
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>
>
> -- 
> Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl
>

Jason Zhao wrote:
> Adam Leventhal wrote:
> > Hi Jason,
> >
> > It would appear that your shell is a 32-bit process and
you''re
> > recording the stack on entry to exece rather than the return. That is
> > to say, you''re recording the stack of your shell rather than
the stack
> > of the 64-bit ls process:
> >
> > # dtrace -n ''syscall::exece:return{ stack(); ustack();
}''dtrace:
> > description ''syscall::exece:return'' matched 1 probe
> > CPU     ID                    FUNCTION:NAME
> >   1  82155                     exece:return
> >               unix`sys_syscall32+0x1fc
> >
> >               0xfffffd7fff3bd8da
>
> Yes, my shell is 32-bit, as following:
> 
> # file /usr/bin/bash
> /usr/bin/bash:    ELF 32-bit LSB executable 80386 Version 1 [FPU],
> dynamically linked, stripped
> 
> In other words, I should have run 64-bit bash other than 32-bit one. So
> that I could get 64-bit address.
Solaris doesn''t ship a 64bit version of "bash" (yet ;
I''ll work on that
soon), right now the only 64bit shell shipped with the OS is ksh93, e.g.
- /usr/bin/ksh93 is a link to "isaexec" which selects a 32bit or 64bit
version of ksh93 based on /usr/bin/isalist output
- /usr/bin/i86/ksh93 is 32bit/i386
- /usr/bin/amd64/ksh93 is 64bit/AMD64
- /usr/bin/sparcv7/ksh93 is 32bit/SPARC
- /usr/bin/sparcv9/ksh93 is 64bit/SPARC
- /usr/bin/s390/ksh93 is 32bit/SystemZ
- /usr/bin/s390x/ksh93 is 64bit/SystemZ

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix
programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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?

Thank you, Roland,

Roland Mainz wrote:
> Jason Zhao wrote:
>   
>> Adam Leventhal wrote:
>>     
>>> Hi Jason,
>>>
>>> It would appear that your shell is a 32-bit process and
you''re
>>> recording the stack on entry to exece rather than the return. That
is
>>> to say, you''re recording the stack of your shell rather
than the stack
>>> of the 64-bit ls process:
>>>
>>> # dtrace -n ''syscall::exece:return{ stack(); ustack();
}''dtrace:
>>> description ''syscall::exece:return'' matched 1
probe
>>> CPU     ID                    FUNCTION:NAME
>>>   1  82155                     exece:return
>>>               unix`sys_syscall32+0x1fc
>>>
>>>               0xfffffd7fff3bd8da
>>>       
>> Yes, my shell is 32-bit, as following:
>>
>> # file /usr/bin/bash
>> /usr/bin/bash:    ELF 32-bit LSB executable 80386 Version 1 [FPU],
>> dynamically linked, stripped
>>
>> In other words, I should have run 64-bit bash other than 32-bit one. So
>> that I could get 64-bit address.
>>     
>
> Solaris doesn''t ship a 64bit version of "bash" (yet ;
I''ll work on that
> soon), right now the only 64bit shell shipped with the OS is ksh93, e.g.
> - /usr/bin/ksh93 is a link to "isaexec" which selects a 32bit or
64bit
> version of ksh93 based on /usr/bin/isalist output
> - /usr/bin/i86/ksh93 is 32bit/i386
> - /usr/bin/amd64/ksh93 is 64bit/AMD64
> - /usr/bin/sparcv7/ksh93 is 32bit/SPARC
> - /usr/bin/sparcv9/ksh93 is 64bit/SPARC
> - /usr/bin/s390/ksh93 is 32bit/SystemZ
> - /usr/bin/s390x/ksh93 is 64bit/SystemZ
>
> ----
>   
It seems like the 64-bit address not only depends on
shell type, but also depends on utilities(commands)
you run.
I run "/usr/bin/ls" got 32-bit, but "/usr/bin/amd64/ls"
got 64-bit address. Is that because 32-bit application
map to memory with 32-bit address? How the address
space is mapped out for a 64 bit application and for
32-bit application?

# file /usr/bin/amd64/ksh93
/usr/bin/amd64/ksh93:    ELF 64-bit LSB executable AMD64 Version 1 [SSE 
FXSR FPU], dynamically linked, not stripped, no debugging information 
available

# /usr/bin/amd64/ksh93
# dtrace -n ''syscall::exece:return{ stack(); ustack(); }''
dtrace: description ''syscall::exece:return'' matched 1 probe
CPU     ID                    FUNCTION:NAME
  0  59013                     exece:return
              unix`_sys_sysenter_post_swapgs+0x14b              <----- 
run /usr/bin/amd64/ls

              0xfffffd7fff3bbaea

  0  59013                     exece:return
              unix`_sys_sysenter_post_swapgs+0x14b               <---- 
run /usr/bin/ls

              0xfefc50c2

Thanks
Jason
> Bye,
> Roland
>
>

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

Hi Jason,

Jason Zhao wrote:
> Hi, Nicolas:
>
> Nicolas Williams wrote:
>   
>> On Wed, Dec 17, 2008 at 10:53:28PM +0800, Jason Zhao wrote:
>>   
>>     
>>
>> 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?
>   
The shell forks, and the child process calls exece.  ls itself
does not use exece.
max
> Thanks
> Jason
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
>

max at bruningsystems.com wrote:
> Hi Jason,
>
> Jason Zhao wrote:
>   
>> Hi, Nicolas:
>>
>> Nicolas Williams wrote:
>>   
>>     
>>> On Wed, Dec 17, 2008 at 10:53:28PM +0800, Jason Zhao wrote:
>>>   
>>>     
>>>
>>> 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?
>>   
>>     
> The shell forks, and the child process calls exece.  ls itself
> does not use exece.
>   
Oh, Thank you, Max. :)

Jason
> max
>
>   
>> Thanks
>> Jason
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>
>>   
>>     
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

On Thu, Dec 18, 2008 at 10:28:22AM +0800, Jason Zhao
wrote:
> It seems like the 64-bit address not only depends on
> shell type, but also depends on utilities(commands)
> you run.
The address size depends on the binary type of the program being run by
the process you''re looking at.

Most utilities in /usr/bin are 32-bit programs only, with some having
/usr/bin/amd64 and /usr/bin/sparv9 variants.  Those utilities are there
for a reason.  ls(1) has a 64-bit variant because time_t is larger in
64-bit and ls(1) deals with dates.  And so on.
> I run "/usr/bin/ls" got 32-bit, but "/usr/bin/amd64/ls"
> got 64-bit address. Is that because 32-bit application
> map to memory with 32-bit address? How the address
> space is mapped out for a 64 bit application and for
> 32-bit application?
ls(1) is also special in that by default you get the 32-bit version --
you have to explicitly run the 64-bit version if you want that version.

Nico
--

>ls(1) is also special in that by default you get the 32-bit version --
>you have to explicitly run the 64-bit version if you want that version.
And that''s only because of some benchmark (kenbus?)

Casper

Casper.Dik at Sun.COM wrote:
> 
>> ls(1) is also special in that by default you get the 32-bit version --
>> you have to explicitly run the 64-bit version if you want that version.
> 
> And that''s only because of some benchmark (kenbus?)
Even on AMD64, or that''s just the way it was on SPARC?

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering

>Casper.Dik at Sun.COM wrote:
>> 
>>> ls(1) is also special in that by default you get the 32-bit version
--
>>> you have to explicitly run the 64-bit version if you want that
version.
>> 
>> And that''s only because of some benchmark (kenbus?)
>
>Even on AMD64, or that''s just the way it was on SPARC?
It''s the exec, I think, not the different flavor of the executable.

Casper