Hi all,
I m trying to get the st_dev and st_ino for a specified command, say
''ls'', a strange thing is the st_dev is always correct but the
st_ino is
always ''0''.
-----ls.d-----
#!/usr/sbin/dtrace -s
#pragma D option quiet
syscall::lstat*:entry
/ execname == "ls" /
{
self->pathp = copyinstr(arg0);
self->statptr = arg1;
}
syscall::lstat*:return
/ self->pathp != NULL /
{
self->stat = (struct stat *)copyin(self->statptr, sizeof(struct
stat));
printf("%s dev:%u ino:%lld nlink:%ld size:%lld bsize:%ld nblk:%ld
fstype:%s\n",
self->pathp,
self->stat->st_dev,
(long long)self->stat->st_ino,
(long)self->stat->st_nlink,
(long long)self->stat->st_size,
(long)self->stat->st_blksize,
(long)self->stat->st_blocks,
self->stat->st_fstype
);
}
$ ls -li /usr/include/stdio.h
11530 -rw-r--r-- 1 root bin 11853 2004 11? 10
/usr/include/stdio.h
# ls.d
/usr/include/stdio.h dev:7340100 ino:0 nlink:0 size:0 bsize:7562869
nblk:0 fstype:
^C
The attributes of /usr/include/stdio.h:
File system device: 28, 68
Inode: 11530
Number of links: 1
File size: 11853
Preferred block size: 8192
Number of blocks: 24
File system type: ufs
Any ideas about it?
Thanks
--
John Cui
x82195
John Cui wrote:> Hi all, > > I m trying to get the st_dev and st_ino for a specified command, say > ''ls'', a strange thing is the st_dev is always correct but the st_ino is > always ''0''.This is because you have a 32 bit stat structure being copied into a 64bit structure. If you use the 64 bit ls binary then you get the correct results: # dtrace -s stat.d /etc/passwd dev:95702394024755200 ino:0 nlink:477748 size:0 bsize:0 nblk:8459575393899249664 fstype: /etc/passwd dev:365072220370 ino:477748 nlink:1 size:647 bsize:8192 nblk:2 fstype:ufs : enoexec.eu FSS 2 $; ls -li /etc/passwd 477748 -rw-r--r-- 1 root sys 647 Mar 3 21:34 /etc/passwd : enoexec.eu FSS 3 $; /usr/bin/sparcv9/ls -li /etc/passwd 477748 -rw-r--r-- 1 root sys 647 Mar 3 21:34 /etc/passwd : enoexec.eu FSS 4 $; --chris> > -----ls.d----- > #!/usr/sbin/dtrace -s > > #pragma D option quiet > > > syscall::lstat*:entry > / execname == "ls" / > { > self->pathp = copyinstr(arg0); > self->statptr = arg1; > } > > syscall::lstat*:return > / self->pathp != NULL / > { > self->stat = (struct stat *)copyin(self->statptr, sizeof(struct stat)); > printf("%s dev:%u ino:%lld nlink:%ld size:%lld bsize:%ld nblk:%ld > fstype:%s\n", > self->pathp, > self->stat->st_dev, > (long long)self->stat->st_ino, > (long)self->stat->st_nlink, > (long long)self->stat->st_size, > (long)self->stat->st_blksize, > (long)self->stat->st_blocks, > self->stat->st_fstype > ); > } > > $ ls -li /usr/include/stdio.h > 11530 -rw-r--r-- 1 root bin 11853 2004 11? 10 > /usr/include/stdio.h > > # ls.d > /usr/include/stdio.h dev:7340100 ino:0 nlink:0 size:0 bsize:7562869 > nblk:0 fstype: > ^C > > The attributes of /usr/include/stdio.h: > File system device: 28, 68 > Inode: 11530 > Number of links: 1 > File size: 11853 > Preferred block size: 8192 > Number of blocks: 24 > File system type: ufs > > Any ideas about it? > > Thanks >-- Chris Gerhard. __o __o __o PTS in Europe _`\<,`\<,`\<,_ Sun Microsystems Limited (*)/---/---/ (*) Phone: +44 (0) 1252 426033 (ext 26033) ----------------------------------------------------------- http://blogs.sun.com/chrisg ----------------------------------------------------------- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060316/448885d1/attachment.bin>
Actually there''s another problem: you''re copying in the stat
structure for
both lstat and lstat64 system calls. In fact, you''ll need a copy of the
return probe for lstat and lstat64 per ISA. Something like:
syscall::lstat:return
/self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_ILP32/
{
self->st32 = (struct stat32 *)copyin(self->statptr,
sizeof(struct stat32));
...
}
syscall::lstat:return
/self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_LP64/
{
self->st = (struct stat *)copyin(self->statptr,
sizeof(struct stat));
...
}
syscall::lstat64:return
/self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_ILP32/
{
self->st64_32 = (struct stat64_32 *)copyin(self->statptr,
sizeof(struct stat64_32));
...
}
syscall::lstat64:return
/self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_LP64/
{
self->st64 = (struct stat64 *)copyin(self->statptr,
sizeof(struct stat64));
...
}
Hope that helps.
Adam
On Thu, Mar 16, 2006 at 08:42:42AM +0000, Chris Gerhard
wrote:> John Cui wrote:
> >Hi all,
> >
> >I m trying to get the st_dev and st_ino for a specified command, say
> >''ls'', a strange thing is the st_dev is always correct
but the st_ino is
> >always ''0''.
>
> This is because you have a 32 bit stat structure being copied into a
> 64bit structure. If you use the 64 bit ls binary then you get the
> correct results:
>
> # dtrace -s stat.d
> /etc/passwd dev:95702394024755200 ino:0 nlink:477748 size:0 bsize:0
> nblk:8459575393899249664 fstype:
> /etc/passwd dev:365072220370 ino:477748 nlink:1 size:647 bsize:8192
> nblk:2 fstype:ufs
>
> : enoexec.eu FSS 2 $; ls -li /etc/passwd
> 477748 -rw-r--r-- 1 root sys 647 Mar 3 21:34
> /etc/passwd
> : enoexec.eu FSS 3 $; /usr/bin/sparcv9/ls -li /etc/passwd
> 477748 -rw-r--r-- 1 root sys 647 Mar 3 21:34
> /etc/passwd
> : enoexec.eu FSS 4 $;
>
> --chris
>
> >
> >-----ls.d-----
> >#!/usr/sbin/dtrace -s
> >
> >#pragma D option quiet
> >
> >
> >syscall::lstat*:entry
> >/ execname == "ls" /
> >{
> > self->pathp = copyinstr(arg0);
> > self->statptr = arg1;
> >}
> >
> >syscall::lstat*:return
> >/ self->pathp != NULL /
> >{
> > self->stat = (struct stat *)copyin(self->statptr,
sizeof(struct stat));
> > printf("%s dev:%u ino:%lld nlink:%ld size:%lld bsize:%ld
nblk:%ld
> >fstype:%s\n",
> > self->pathp,
> > self->stat->st_dev,
> > (long long)self->stat->st_ino,
> > (long)self->stat->st_nlink,
> > (long long)self->stat->st_size,
> > (long)self->stat->st_blksize,
> > (long)self->stat->st_blocks,
> > self->stat->st_fstype
> > );
> >}
> >
> >$ ls -li /usr/include/stdio.h
> >11530 -rw-r--r-- 1 root bin 11853 2004 11? 10
> >/usr/include/stdio.h
> >
> ># ls.d
> >/usr/include/stdio.h dev:7340100 ino:0 nlink:0 size:0 bsize:7562869
> >nblk:0 fstype:
> >^C
> >
> >The attributes of /usr/include/stdio.h:
> > File system device: 28, 68
> > Inode: 11530
> > Number of links: 1
> > File size: 11853
> > Preferred block size: 8192
> > Number of blocks: 24
> > File system type: ufs
> >
> >Any ideas about it?
> >
> >Thanks
> >
>
>
> --
> Chris Gerhard. __o __o __o
> PTS in Europe _`\<,`\<,`\<,_
> Sun Microsystems Limited (*)/---/---/ (*)
> Phone: +44 (0) 1252 426033 (ext 26033)
> -----------------------------------------------------------
> http://blogs.sun.com/chrisg
> -----------------------------------------------------------
> NOTICE: This email message is for the sole use of the
> intended recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use,
> disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact
> the sender by reply email and destroy all copies of the
> original message.
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Hi Adam and Chris, Thanks for your replies. It''s my want, ;-) I took it for granted that lstat and lstat64 would handle it. So it confused me. PR_MODEL_ILP32 and PR_MODEL_LP64 are the points, I totally forgot them, :-( Thanks! Adam Leventhal wrote:> Actually there''s another problem: you''re copying in the stat structure for > both lstat and lstat64 system calls. In fact, you''ll need a copy of the > return probe for lstat and lstat64 per ISA. Something like: > > syscall::lstat:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_ILP32/ > { > self->st32 = (struct stat32 *)copyin(self->statptr, > sizeof(struct stat32)); > ... > } > > syscall::lstat:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_LP64/ > { > self->st = (struct stat *)copyin(self->statptr, > sizeof(struct stat)); > ... > } > > syscall::lstat64:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_ILP32/ > { > self->st64_32 = (struct stat64_32 *)copyin(self->statptr, > sizeof(struct stat64_32)); > ... > } > > syscall::lstat64:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_LP64/ > { > self->st64 = (struct stat64 *)copyin(self->statptr, > sizeof(struct stat64)); > ... > } > > Hope that helps. > > Adam > > On Thu, Mar 16, 2006 at 08:42:42AM +0000, Chris Gerhard wrote: > >> John Cui wrote: >> >>> Hi all, >>> >>> I m trying to get the st_dev and st_ino for a specified command, say >>> ''ls'', a strange thing is the st_dev is always correct but the st_ino is >>> always ''0''. >>> >> This is because you have a 32 bit stat structure being copied into a >> 64bit structure. If you use the 64 bit ls binary then you get the >> correct results: >> >> # dtrace -s stat.d >> /etc/passwd dev:95702394024755200 ino:0 nlink:477748 size:0 bsize:0 >> nblk:8459575393899249664 fstype: >> /etc/passwd dev:365072220370 ino:477748 nlink:1 size:647 bsize:8192 >> nblk:2 fstype:ufs >> >> : enoexec.eu FSS 2 $; ls -li /etc/passwd >> 477748 -rw-r--r-- 1 root sys 647 Mar 3 21:34 >> /etc/passwd >> : enoexec.eu FSS 3 $; /usr/bin/sparcv9/ls -li /etc/passwd >> 477748 -rw-r--r-- 1 root sys 647 Mar 3 21:34 >> /etc/passwd >> : enoexec.eu FSS 4 $; >> >> --chris >> >> >>> -----ls.d----- >>> #!/usr/sbin/dtrace -s >>> >>> #pragma D option quiet >>> >>> >>> syscall::lstat*:entry >>> / execname == "ls" / >>> { >>> self->pathp = copyinstr(arg0); >>> self->statptr = arg1; >>> } >>> >>> syscall::lstat*:return >>> / self->pathp != NULL / >>> { >>> self->stat = (struct stat *)copyin(self->statptr, sizeof(struct stat)); >>> printf("%s dev:%u ino:%lld nlink:%ld size:%lld bsize:%ld nblk:%ld >>> fstype:%s\n", >>> self->pathp, >>> self->stat->st_dev, >>> (long long)self->stat->st_ino, >>> (long)self->stat->st_nlink, >>> (long long)self->stat->st_size, >>> (long)self->stat->st_blksize, >>> (long)self->stat->st_blocks, >>> self->stat->st_fstype >>> ); >>> } >>> >>> $ ls -li /usr/include/stdio.h >>> 11530 -rw-r--r-- 1 root bin 11853 2004 11? 10 >>> /usr/include/stdio.h >>> >>> # ls.d >>> /usr/include/stdio.h dev:7340100 ino:0 nlink:0 size:0 bsize:7562869 >>> nblk:0 fstype: >>> ^C >>> >>> The attributes of /usr/include/stdio.h: >>> File system device: 28, 68 >>> Inode: 11530 >>> Number of links: 1 >>> File size: 11853 >>> Preferred block size: 8192 >>> Number of blocks: 24 >>> File system type: ufs >>> >>> Any ideas about it? >>> >>> Thanks >>> >>> >> -- >> Chris Gerhard. __o __o __o >> PTS in Europe _`\<,`\<,`\<,_ >> Sun Microsystems Limited (*)/---/---/ (*) >> Phone: +44 (0) 1252 426033 (ext 26033) >> ----------------------------------------------------------- >> http://blogs.sun.com/chrisg >> ----------------------------------------------------------- >> NOTICE: This email message is for the sole use of the >> intended recipient(s) and may contain confidential and >> privileged information. Any unauthorized review, use, >> disclosure or distribution is prohibited. >> If you are not the intended recipient, please contact >> the sender by reply email and destroy all copies of the >> original message. >> >> > > > > >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > >-- John Cui x82195
Hi, I still another question, how to print st_size? Adam Leventhal wrote:> Actually there''s another problem: you''re copying in the stat structure for > both lstat and lstat64 system calls. In fact, you''ll need a copy of the > return probe for lstat and lstat64 per ISA. Something like: > > syscall::lstat:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_ILP32/ > { > self->st32 = (struct stat32 *)copyin(self->statptr, > sizeof(struct stat32)); > ... > } > > syscall::lstat:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_LP64/ > { > self->st = (struct stat *)copyin(self->statptr, > sizeof(struct stat)); > ... > } > > syscall::lstat64:return > /self->statptr != NULL && curpsinfo->pr_dmodel == PR_MODEL_ILP32/ > { > self->st64_32 = (struct stat64_32 *)copyin(self->statptr, > sizeof(struct stat64_32)); > ... > } >I added the following line in this probe: printf("size: %lld\n", (long long)self->st64_32->st_size ); it always produces error: dtrace: error on enabled probe ID 5 (ID 390: syscall::lstat64:return): invalid alignment (0xffffffff97fac06c) in action #2 at DIF offset 20 Even I change the pair of %lld and (long long), the results are same. Thanks, -- John Cui x82195
On Fri, Mar 17, 2006 at 03:30:13PM +0800, John Cui wrote:> I added the following line in this probe: > printf("size: %lld\n", (long long)self->st64_32->st_size ); > > it always produces error: > dtrace: error on enabled probe ID 5 (ID 390: syscall::lstat64:return): > invalid alignment (0xffffffff97fac06c) in action #2 at DIF offset 20 > > Even I change the pair of %lld and (long long), the results are same.You''ve hit a bug in DTrace. The problem is that we''re asserting alignment in a case where the x86 architecture doesn''t actually require it. I''ve filed this bug for you: 6400262 DTrace requires more alignment than necessary Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam, It''s kind of strange, I hit a DTrace bug, :-P Thanks. Adam Leventhal wrote:> On Fri, Mar 17, 2006 at 03:30:13PM +0800, John Cui wrote: > >> I added the following line in this probe: >> printf("size: %lld\n", (long long)self->st64_32->st_size ); >> >> it always produces error: >> dtrace: error on enabled probe ID 5 (ID 390: syscall::lstat64:return): >> invalid alignment (0xffffffff97fac06c) in action #2 at DIF offset 20 >> >> Even I change the pair of %lld and (long long), the results are same. >> > > You''ve hit a bug in DTrace. The problem is that we''re asserting alignment > in a case where the x86 architecture doesn''t actually require it. I''ve > filed this bug for you: > > 6400262 DTrace requires more alignment than necessary > > Adam > >-- John Cui x82195