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.
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
