Manoj Joseph
2006-Jan-04 11:46 UTC
[dtrace-discuss] Dtrace not picking up the symbols for user stack.
Hi,
I was trying to get the user stack from a probe. Like this:
bash-3.00# dtrace -n ''fbt:zfs:zfs_getsecattr:{ustack();
exit(0);}''
dtrace: description ''fbt:zfs:zfs_getsecattr:'' matched 2 probes
CPU ID FUNCTION:NAME
0 37508 zfs_getsecattr:entry
0xff31d114
0xff384da0
0x13d40
0x12018
0x11200
No symbols! The binary is not stripped.
bash-3.00# file /usr/bin/ls
/usr/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped, no debugging information available
bash-3.00# /usr/ccs/bin/nm /usr/bin/ls | grep main
[142] | 71488| 3132|FUNC |GLOB |0 |9 |main
[196] | 155748| 0|FUNC |GLOB |0 |UNDEF |textdomain
Why is dtrace not picking up the symbols?
I am on snv_30.
bash-3.00# uname -a
SunOS pdruv2 5.11 snv_30 sun4u sparc SUNW,Sun-Fire-V240
Regards,
Manoj
Roch Bourbonnais - Performance Engineering
2006-Jan-04 13:21 UTC
[dtrace-discuss] Dtrace not picking up the symbols for user stack.
This is because the process that triggered the problem has
itself exited before your dtrace command tried to translate
the addresses into symbols. If you start the triggering
command with a -c argument this may solve your issue.
dtrace -n ''fbt:zfs:zfs_readdir:{ustack(); exit(0);}'' -c
"ls /zfs"
^^^^^^^^^^^^
...
CPU ID FUNCTION:NAME
0 33305 zfs_readdir:entry
libc.so.1`getdents64+0x4
ls`rddir+0x58
ls`pdirectory+0xf0
ls`main+0xaa4
ls`_start+0x108
-r
Manoj Joseph writes:
> Hi,
>
> I was trying to get the user stack from a probe. Like this:
>
> bash-3.00# dtrace -n ''fbt:zfs:zfs_getsecattr:{ustack();
exit(0);}''
> dtrace: description ''fbt:zfs:zfs_getsecattr:'' matched 2
probes
> CPU ID FUNCTION:NAME
> 0 37508 zfs_getsecattr:entry
>
> 0xff31d114
> 0xff384da0
> 0x13d40
> 0x12018
> 0x11200
>
> No symbols! The binary is not stripped.
>
> bash-3.00# file /usr/bin/ls
> /usr/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically
> linked, not stripped, no debugging information available
>
> bash-3.00# /usr/ccs/bin/nm /usr/bin/ls | grep main
> [142] | 71488| 3132|FUNC |GLOB |0 |9 |main
> [196] | 155748| 0|FUNC |GLOB |0 |UNDEF |textdomain
>
> Why is dtrace not picking up the symbols?
>
> I am on snv_30.
> bash-3.00# uname -a
> SunOS pdruv2 5.11 snv_30 sun4u sparc SUNW,Sun-Fire-V240
>
> Regards,
> Manoj
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
Adam Leventhal
2006-Jan-04 16:04 UTC
[dtrace-discuss] Dtrace not picking up the symbols for user stack.
Hi Manoj, The problem is that while the ustack() action grabs the program counter stack at probe time, the program counters are resolved to symbols later when the buffer is snapshotted by the user-land consumer. In addition to using the -c or -p options as Roch suggested, you can also use the stop() action to ensure the process doesn''t exit until the ustack() has been processed as described toward the end of this page: http://docs.sun.com/app/docs/doc/817-6223/6mlkidlmm?a=view Adam On Wed, Jan 04, 2006 at 05:16:58PM +0530, Manoj Joseph wrote:> Hi, > > I was trying to get the user stack from a probe. Like this: > > bash-3.00# dtrace -n ''fbt:zfs:zfs_getsecattr:{ustack(); exit(0);}'' > dtrace: description ''fbt:zfs:zfs_getsecattr:'' matched 2 probes > CPU ID FUNCTION:NAME > 0 37508 zfs_getsecattr:entry > > 0xff31d114 > 0xff384da0 > 0x13d40 > 0x12018 > 0x11200 > > No symbols! The binary is not stripped. > > bash-3.00# file /usr/bin/ls > /usr/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, not stripped, no debugging information available > > bash-3.00# /usr/ccs/bin/nm /usr/bin/ls | grep main > [142] | 71488| 3132|FUNC |GLOB |0 |9 |main > [196] | 155748| 0|FUNC |GLOB |0 |UNDEF |textdomain > > Why is dtrace not picking up the symbols? > > I am on snv_30. > bash-3.00# uname -a > SunOS pdruv2 5.11 snv_30 sun4u sparc SUNW,Sun-Fire-V240 > > Regards, > Manoj > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl