Hi
I would like to get the file name for a file descriptor in my output, but I have
problems using it when I specify the data model to be 32bit:
trond at muffin> dtrace -n ''syscall::close:return {
trace(fds[arg0].fi_pathname); }''
dtrace: description ''syscall::close:return '' matched 1 probe
But when I try to set the data model I get:
trond at muffin> dtrace -32 -n ''syscall::close:return {
trace(fds[arg0].fi_pathname); }''
dtrace: invalid probe specifier syscall::close:return {
trace(fds[arg0].fi_pathname); }: in action list: fds has not yet been declared
or assigned
I am specifying -32 since my application (containing my own provider) is a 32bit
application. Is it not possible to use the fds if I select another data model
than the default? Or do I have to modify my scripts so they work regardless of
the selected data model?
Trond
This message posted from opensolaris.org
Hi Trond, When you specify a data model that doesn''t match that of the kernel, libdtrace can''t load the CTF data for kernel modules. If you look at /usr/lib/dtrace/io.d where the fds[] array is defined, you''ll see that it has this line: #pragma D depends_on module unix Since the unix module can''t be loaded, the file can''t be processed so you don''t have the variables it defines. (If you run dtrace(1M) with DTRACE_DEBUG set, you''ll see a note to this effect in the output.) We''ve talked about a fix for problems like this were we''d like to have multiple data models within the same D program, but it''s immensely complex and I wouldn''t expect a fix any time soon. Feel free to file a bug on OpenSolaris.org so we can track the issue. It''s a tricky issue to work around because you have to dereference 64-bit pointers to access the kernel data. Would it be possible to define versions of your program''s structures that matched the 32-bit implementation when compiled under a 64-bit data model? We do this sort of thing a bunch for 32-bit system calls on a 64-bit kernel (see, stat64_32 for example). Adam On Tue, Oct 10, 2006 at 03:23:27AM -0700, Trond Norbye wrote:> Hi > > I would like to get the file name for a file descriptor in my output, but I have problems using it when I specify the data model to be 32bit: > > trond at muffin> dtrace -n ''syscall::close:return { trace(fds[arg0].fi_pathname); }'' > dtrace: description ''syscall::close:return '' matched 1 probe > > But when I try to set the data model I get: > trond at muffin> dtrace -32 -n ''syscall::close:return { trace(fds[arg0].fi_pathname); }'' > dtrace: invalid probe specifier syscall::close:return { trace(fds[arg0].fi_pathname); }: in action list: fds has not yet been declared or assigned > > I am specifying -32 since my application (containing my own provider) is a 32bit application. Is it not possible to use the fds if I select another data model than the default? Or do I have to modify my scripts so they work regardless of the selected data model? > > Trond > > > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
If you have access to a machine that''s pre-US-IIe, would it work to boot the 32 bit kernel? Chip Adam Leventhal wrote:> Hi Trond, > > When you specify a data model that doesn''t match that of the kernel, > libdtrace can''t load the CTF data for kernel modules. If you look at > /usr/lib/dtrace/io.d where the fds[] array is defined, you''ll see that > it has this line: > > #pragma D depends_on module unix > > Since the unix module can''t be loaded, the file can''t be processed so you > don''t have the variables it defines. (If you run dtrace(1M) with DTRACE_DEBUG > set, you''ll see a note to this effect in the output.) > > We''ve talked about a fix for problems like this were we''d like to have > multiple data models within the same D program, but it''s immensely complex > and I wouldn''t expect a fix any time soon. Feel free to file a bug on > OpenSolaris.org so we can track the issue. > > It''s a tricky issue to work around because you have to dereference 64-bit > pointers to access the kernel data. Would it be possible to define versions > of your program''s structures that matched the 32-bit implementation when > compiled under a 64-bit data model? We do this sort of thing a bunch for > 32-bit system calls on a 64-bit kernel (see, stat64_32 for example). > > Adam > > On Tue, Oct 10, 2006 at 03:23:27AM -0700, Trond Norbye wrote: > >> Hi >> >> I would like to get the file name for a file descriptor in my output, but I have problems using it when I specify the data model to be 32bit: >> >> trond at muffin> dtrace -n ''syscall::close:return { trace(fds[arg0].fi_pathname); }'' >> dtrace: description ''syscall::close:return '' matched 1 probe >> >> But when I try to set the data model I get: >> trond at muffin> dtrace -32 -n ''syscall::close:return { trace(fds[arg0].fi_pathname); }'' >> dtrace: invalid probe specifier syscall::close:return { trace(fds[arg0].fi_pathname); }: in action list: fds has not yet been declared or assigned >> >> I am specifying -32 since my application (containing my own provider) is a 32bit application. Is it not possible to use the fds if I select another data model than the default? Or do I have to modify my scripts so they work regardless of the selected data model? >> >> Trond >> >> >> This message posted from opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > >
You can boot x64 systems 32-bit, but as of Solaris 10 we don''t build or ship a 32-bit kernel for SPARC. Adam On Tue, Oct 10, 2006 at 06:28:35PM -0500, Chip Bennett wrote:> If you have access to a machine that''s pre-US-IIe, would it work to boot > the 32 bit kernel? > > Chip > > Adam Leventhal wrote: > >Hi Trond, > > > >When you specify a data model that doesn''t match that of the kernel, > >libdtrace can''t load the CTF data for kernel modules. If you look at > >/usr/lib/dtrace/io.d where the fds[] array is defined, you''ll see that > >it has this line: > > > >#pragma D depends_on module unix > > > >Since the unix module can''t be loaded, the file can''t be processed so you > >don''t have the variables it defines. (If you run dtrace(1M) with > >DTRACE_DEBUG > >set, you''ll see a note to this effect in the output.) > > > >We''ve talked about a fix for problems like this were we''d like to have > >multiple data models within the same D program, but it''s immensely complex > >and I wouldn''t expect a fix any time soon. Feel free to file a bug on > >OpenSolaris.org so we can track the issue. > > > >It''s a tricky issue to work around because you have to dereference 64-bit > >pointers to access the kernel data. Would it be possible to define versions > >of your program''s structures that matched the 32-bit implementation when > >compiled under a 64-bit data model? We do this sort of thing a bunch for > >32-bit system calls on a 64-bit kernel (see, stat64_32 for example). > > > >Adam > > > >On Tue, Oct 10, 2006 at 03:23:27AM -0700, Trond Norbye wrote: > > > >>Hi > >> > >>I would like to get the file name for a file descriptor in my output, but > >>I have problems using it when I specify the data model to be 32bit: > >> > >>trond at muffin> dtrace -n ''syscall::close:return { > >>trace(fds[arg0].fi_pathname); }'' > >>dtrace: description ''syscall::close:return '' matched 1 probe > >> > >>But when I try to set the data model I get: > >>trond at muffin> dtrace -32 -n ''syscall::close:return { > >>trace(fds[arg0].fi_pathname); }'' > >>dtrace: invalid probe specifier syscall::close:return { > >>trace(fds[arg0].fi_pathname); }: in action list: fds has not yet been > >>declared or assigned > >> > >>I am specifying -32 since my application (containing my own provider) is > >>a 32bit application. Is it not possible to use the fds if I select > >>another data model than the default? Or do I have to modify my scripts so > >>they work regardless of the selected data model? > >> > >>Trond > >> > >> > >>This message posted from opensolaris.org > >>_______________________________________________ > >>dtrace-discuss mailing list > >>dtrace-discuss at opensolaris.org > >> > > > >-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl