I''m wondering if this is expected behavior, or a bug.
Given this D:
# cat smb_logon.d
pid$target::smb_logon:entry {
add=&((struct netr_client *)arg0)->username;
printf("%p",add);
exit();
}
and this defintion:
typedef struct netr_client {
uint16_t logon_level;
char *username; /* request username */
char *domain; /* request domain */
char *e_username; /* effective username */
char *e_domain; /* effective domain */
[...]
} netr_client_t;
On a 64-bit x86 system (SunOS smar-x 5.11 snv_127 i86pc):
# dtrace -s smb_logon.d -p `pgrep smbd`
dtrace: script ''smb_logon.d'' matched 1 probe
CPU ID FUNCTION:NAME
2 66800 smb_logon:entry 810aef8
This works, but since it''s a 32-bit application the address is
''wrong''. It should be 810aef4.
# dtrace -32 -s smb_logon.d -p `pgrep smbd`
dtrace: failed to compile script smb_logon.d: line 2: operator -> cannot be
applied to a forward declaration: no struct
netr_client definition is available
So... where is dtrace looking for the ctf info? It can''t be in the
binary, as mdb can find the definition:
# mdb -p `pgrep smbd`
> ::print -ta struct netr_client
0 struct netr_client {
0 uint16_t logon_level
4 char *username
8 char *domain
c char *e_username
[...]
If I change the D to:
add=&((netr_client_t *)arg0)->username;
it''s even more bizarre. The 64-bit version ''works''
again:
# dtrace -s smb_logon2.d -p `pgrep smbd`
dtrace: script ''smb_logon2.d'' matched 1 probe
CPU ID FUNCTION:NAME
2 66800 smb_logon:entry 810aef8
but -32 doesn''t even come close:
# dtrace -32 -s smb_logon2.d -p `pgrep smbd`
dtrace: failed to compile script smb_logon2.d: line 2: syntax error near
")"
Any thoughts or ideas?
-Drew
Hi Drew,> I''m wondering if this is expected behavior, or a bug.Expected but not all that obvious really. See below.> Given this D: > > # cat smb_logon.d > pid$target::smb_logon:entry { > add=&((struct netr_client *)arg0)->username; > printf("%p",add); > exit(); > } > > and this defintion: > > typedef struct netr_client { > uint16_t logon_level; > char *username; /* request username */ > char *domain; /* request domain */ > char *e_username; /* effective username */ > char *e_domain; /* effective domain */ > [...] > } netr_client_t; > > On a 64-bit x86 system (SunOS smar-x 5.11 snv_127 i86pc): > > # dtrace -s smb_logon.d -p `pgrep smbd` > dtrace: script ''smb_logon.d'' matched 1 probe > CPU ID FUNCTION:NAME > 2 66800 smb_logon:entry 810aef8 > > This works, but since it''s a 32-bit application the address is ''wrong''. > It should be 810aef4. > > # dtrace -32 -s smb_logon.d -p `pgrep smbd` > dtrace: failed to compile script smb_logon.d: line 2: operator -> cannot > be applied to a forward declaration: no struct netr_client definition is > available > > So... where is dtrace looking for the ctf info? It can''t be in the > binary, as mdb can find the definition: > > # mdb -p `pgrep smbd`We currently don''t employ any ctf that is available in userland. The definition you are finding is most likely from the ''smbsrv'' kernel module. The reason that it "works" on 64-bit but not on 32-bit is that we don''t support mixed-mode. This means that if we have a 32-bit data model in userland and a 64-bit data model in kernel we won''t read any CTF from the kernel. In that case we no longer have the netr_client_t definition available and we can''t carry on. What you need to do is to #include the the header containing the definition of netr_client_t and invoke the pre-processor with the ''-C'' flag. Jon.