dtrace discuss - Oct 2006 - about disassembling in-core(or kernel crash dump) dtrace instructions

I am aware that the dtrace compiler can show the ''assembly''
code in
generates.

But is there a facility (mdb module ?) to dump this level of 
information  from a  kernel crashdump ? I can manually do this
for a small number of actions, but becomes very tedious when the
number of actions grows to hundreds.

Please copy me in your reply as I am not on this alias.

Thanks
Bhaskar

Bhaskar,

With DTrace, are you talking about the DIF code (DTrace Intermediate 
Format) that your D program gets compiled into?  So in the case of the 
crash dump, you want to display the DIF programs that were running at 
the time of the crash dump?

Just trying to clarify.  Thanks.

Chip

Bhaskar Sarkar wrote:
> I am aware that the dtrace compiler can show the
''assembly'' code in
> generates.
>
> But is there a facility (mdb module ?) to dump this level of 
> information  from a  kernel crashdump ? I can manually do this
> for a small number of actions, but becomes very tedious when the
> number of actions grows to hundreds.
>
> Please copy me in your reply as I am not on this alias.
>
> Thanks
> Bhaskar
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

>
>
> With DTrace, are you talking about the DIF code (DTrace Intermediate 
> Format) that your D program gets compiled into?  So in the case of the 
> crash dump, you want to display the DIF programs that were running at 
> the time of the crash dump?
Yes exactly, perhaps on a per-consumer basis.

Bhaskar

> I am aware that the dtrace compiler can show the
''assembly'' code in
> generates.
> 
> But is there a facility (mdb module ?) to dump this level of 
> information  from a  kernel crashdump ? I can manually do this
> for a small number of actions, but becomes very tedious when the
> number of actions grows to hundreds.
> 
> Please copy me in your reply as I am not on this alias.
> 
> Thanks
> Bhaskar
The ::difinstr dcmd from the "dtrace" mdb debugging module, which will
be loaded automatically if you look at a crash dump, can be used to
disassemble DIF.  You can give it a repeat count for a group of instructions.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

On Thu, Oct 12, 2006 at 10:00:48AM -0700, Michael Shapiro
wrote:
> 
> > I am aware that the dtrace compiler can show the
''assembly'' code in
> > generates.
> > 
> > But is there a facility (mdb module ?) to dump this level of 
> > information  from a  kernel crashdump ? I can manually do this
> > for a small number of actions, but becomes very tedious when the
> > number of actions grows to hundreds.
> > 
> > Please copy me in your reply as I am not on this alias.
> > 
> > Thanks
> > Bhaskar
> 
> The ::difinstr dcmd from the "dtrace" mdb debugging module, which
will
> be loaded automatically if you look at a crash dump, can be used to
> disassemble DIF.  You can give it a repeat count for a group of
instructions.
You can also use ::difo on a DIF object.  You can get to the DIF object
by looking at the dtrace_predicate_t/dtrace_action_t.  e.g.:

  # dtrace -n BEGIN''{x = "foobar"}'' 
  dtrace: description ''BEGIN'' matched 1 probe

Now with mdb -k:

  # mdb -k
  Loading modules: [ unix krtld genunix specfs dtrace cpu.AuthenticAMD.15 uppc
pcplusmp scsi_vhci zfs random ip sctp arp usba s1394 nca ufs lofs cpc nfs
logindmux ptm sppp ipc ]
  > ::dtrace_state
              ADDR MINOR             PROC NAME                         FILE
               ...
  fffffe9158b50dc0     6 fffffeb8824863d0 dtrace           fffffe891d18aab0
 
  > fffffe9158b50dc0::print -t dtrace_state_t dts_ecbs
  dtrace_ecb_t **dts_ecbs = 0xfffffe831ba46f18
  > *(0xfffffe831ba46f18)::print dtrace_ecb_t dte_action->dta_difo |
::difo
  DIF Object 0xfffffe98f936ce80 (refcnt=3)

  ADDR             OPCODE   INSTRUCTION
  fffffe82777a3290 26000101 sets DIF_STRING[1], %r1               !
"foobar"
  fffffe82777a3294 2a050001 stgs %r1, DIF_VAR(500)                ! x
  fffffe82777a3298 23000001 ret  %r1

  NAME             ID   KND SCP FLAG TYPE
  x                500  scl glb w    string by ref (size 256)

  RETURN
  D type (size 0)

Bon Appetit!

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

On Thu 12 Oct 2006 at 10:14AM, Bryan Cantrill wrote:
>   > ::dtrace_state
>               ADDR MINOR             PROC NAME                         FILE
>                ...
>   fffffe9158b50dc0     6 fffffeb8824863d0 dtrace           fffffe891d18aab0
>  
>   > fffffe9158b50dc0::print -t dtrace_state_t dts_ecbs
>   dtrace_ecb_t **dts_ecbs = 0xfffffe831ba46f18
>   > *(0xfffffe831ba46f18)::print dtrace_ecb_t dte_action->dta_difo |
::difo
>   DIF Object 0xfffffe98f936ce80 (refcnt=3)
I''ve definitely bumped up against this being cumbersome.  Not only
might
you have any number of ECBs (which you have to determine in a separate
step), the actions are chained together on a linked list, and you must
walk this list to dump out all of the actions.  For a D program with even
a dozen actions, this gets to be a pain "right quick."

So maybe there''s an RFE here for a walker which, given a
dtrace_state_t,
walks all of associated actions?  Then you''d have something like:

<addr>::walk dtrace_actions | ::print dtrace_action_t dta_difo | ::difo

Thank whoever for ::difo.  I really appreciate having it.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp

On Thu, Oct 12, 2006 at 01:27:07PM -0700, Dan Price
wrote:
> On Thu 12 Oct 2006 at 10:14AM, Bryan Cantrill wrote:
> >   > ::dtrace_state
> >               ADDR MINOR             PROC NAME                        
FILE
> >                ...
> >   fffffe9158b50dc0     6 fffffeb8824863d0 dtrace          
fffffe891d18aab0
> >  
> >   > fffffe9158b50dc0::print -t dtrace_state_t dts_ecbs
> >   dtrace_ecb_t **dts_ecbs = 0xfffffe831ba46f18
> >   > *(0xfffffe831ba46f18)::print dtrace_ecb_t
dte_action->dta_difo | ::difo
> >   DIF Object 0xfffffe98f936ce80 (refcnt=3)
> 
> I''ve definitely bumped up against this being cumbersome.  Not only
might
> you have any number of ECBs (which you have to determine in a separate
> step), the actions are chained together on a linked list, and you must
> walk this list to dump out all of the actions.  For a D program with even
> a dozen actions, this gets to be a pain "right quick."
> 
> So maybe there''s an RFE here for a walker which, given a
dtrace_state_t,
> walks all of associated actions?  Then you''d have something like:
It would be much more useful to have one that walks all ECBs, but add
whatever you want -- this is something that''s easier to code up than
talk
about...
> <addr>::walk dtrace_actions | ::print dtrace_action_t dta_difo |
::difo
> 
> Thank whoever for ::difo.  I really appreciate having it.
No sweat.

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

>So maybe there''s an RFE here for a walker which, given a
dtrace_state_t,
>walks all of associated actions?  Then you''d have something like:
>
><addr>::walk dtrace_actions | ::print dtrace_action_t dta_difo |
::difo
>  
>
Yes, something like a ::walk_ecb walker has needed doing for a while (shame
on me for not logging the RFE or doing it I guess...). Just for general 
interest,
the following ksh script displays all the DIF for any given consumers
actions (I know the script is utter tat but it''s always done the
job...):


# cat ecb_difo
####################################
#!/bin/ksh

# Just pass in the address of a dtrace_state_t

addr=$1

ecbs=$(echo "$addr::print dtrace_state_t dts_ecbs" | mdb -k)
ecbs=$(echo $ecbs|cut -d"=" -f2)
numecb=$(echo "$addr::print dtrace_state_t dts_necbs" | mdb -k)
numecb=$(echo $numecb|cut -d"=" -f2)

echo "$ecbs::array uintptr_t $numecb | ::print uintptr_t | ::grep
\".!=0\" |
::print dtrace_ecb_t dte_action->dta_difo | ::difo" |mdb -k
####################################

This produces output such as:

# ./ecb_difo ffffffff8539f4c0
DIF Object 0xffffffff940e8f00 (refcnt=3)

ADDR             OPCODE   INSTRUCTION
ffffffff921ee700 25000001 setx DIF_INTEGER[0], %r1              ! 0x1
ffffffff921ee704 28000101 ldga DIF_VAR(0), %r1, %r1
ffffffff921ee708 22010001 ldx  [%r1], %r1
ffffffff921ee70c 2a050001 stgs %r1, DIF_VAR(500)                ! iov
ffffffff921ee710 23000001 ret  %r1

NAME             ID   KND SCP FLAG TYPE
iov              500  scl glb w    D type (size 8)

RETURN
D type (size 0)

DIF Object 0xffffffff93f31080 (refcnt=3)

ADDR             OPCODE   INSTRUCTION
ffffffffa1479a20 29010701 ldgs DIF_VAR(107), %r1                ! arg1
ffffffffa1479a24 23000001 ret  %r1

NAME             ID   KND SCP FLAG TYPE
arg1             107  scl glb r    D type (size 8)

RETURN
D type (size 8)

DIF Object 0xffffffff93f31080 (refcnt=3)

ADDR             OPCODE   INSTRUCTION
ffffffffa1479a20 29010701 ldgs DIF_VAR(107), %r1                ! arg1
ffffffffa1479a24 23000001 ret  %r1

NAME             ID   KND SCP FLAG TYPE
arg1             107  scl glb r    D type (size 8)

RETURN
D type (size 8)

DIF Object 0xffffffff940e8f00 (refcnt=3)

ADDR             OPCODE   INSTRUCTION
ffffffff921ee700 25000001 setx DIF_INTEGER[0], %r1              ! 0x1
ffffffff921ee704 28000101 ldga DIF_VAR(0), %r1, %r1
ffffffff921ee708 22010001 ldx  [%r1], %r1
ffffffff921ee70c 2a050001 stgs %r1, DIF_VAR(500)                ! iov
ffffffff921ee710 23000001 ret  %r1

NAME             ID   KND SCP FLAG TYPE
iov              500  scl glb w    D type (size 8)

RETURN
D type (size 0)


Cheers.

Jon.

On Thu, Oct 12, 2006 at 01:27:07PM -0700, Dan Price
wrote:
> So maybe there''s an RFE here for a walker which, given a
dtrace_state_t,
> walks all of associated actions?  Then you''d have something like:
> 
> <addr>::walk dtrace_actions | ::print dtrace_action_t dta_difo |
::difo
If you''re willing to understand the structures a little bit, you can
already
do this, but it can be a bit of a pain:
> ::dtrace_state
            ADDR MINOR             PROC NAME                         FILE
fffffeb75c632800     2 fffffeb75c3863c0 dtrace          
ffffffff8b3ab148
> fffffeb75c632800::print dtrace_state_t dts_necbs
dts_necbs = 0x4
> fffffeb75c632800::print dtrace_state_t dts_ecbs | ::array
''dtrace_ecb_t *'' 4 | ::print ''dtrace_ecb_t
*'' dte_action | ::list dtrace_action_t dta_next | ::print
dtrace_action_t dta_difo | ::difo
Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Duh!

My example obviously needs a ::list iterator applying to the ecb''s
action list. Without it I just pick up the first action...

Bizarrely, I woke up at 4:00am with the thought that what I''d posted
was incorrect. Oh, the joys of jet lag and the collective sub-conscious!
However, I see that Adam has also since posted a correct version.

Jon.
> Yes, something like a ::walk_ecb walker has needed doing for a while 
> (shame
> on me for not logging the RFE or doing it I guess...). Just for 
> general interest,
> the following ksh script displays all the DIF for any given consumers
> actions (I know the script is utter tat but it''s always done the
job...):
>
>
> # cat ecb_difo
> ####################################
> #!/bin/ksh
>
> # Just pass in the address of a dtrace_state_t
>
> addr=$1
>
> ecbs=$(echo "$addr::print dtrace_state_t dts_ecbs" | mdb -k)
> ecbs=$(echo $ecbs|cut -d"=" -f2)
> numecb=$(echo "$addr::print dtrace_state_t dts_necbs" | mdb -k)
> numecb=$(echo $numecb|cut -d"=" -f2)
>
> echo "$ecbs::array uintptr_t $numecb | ::print uintptr_t | ::grep 
> \".!=0\" |
> ::print dtrace_ecb_t dte_action->dta_difo | ::difo" |mdb -k
> ####################################
>
> This produces output such as:
>
> # ./ecb_difo ffffffff8539f4c0
> DIF Object 0xffffffff940e8f00 (refcnt=3)
>
> ADDR             OPCODE   INSTRUCTION
> ffffffff921ee700 25000001 setx DIF_INTEGER[0], %r1              ! 0x1
> ffffffff921ee704 28000101 ldga DIF_VAR(0), %r1, %r1
> ffffffff921ee708 22010001 ldx  [%r1], %r1
> ffffffff921ee70c 2a050001 stgs %r1, DIF_VAR(500)                ! iov
> ffffffff921ee710 23000001 ret  %r1
>
> NAME             ID   KND SCP FLAG TYPE
> iov              500  scl glb w    D type (size 8)
>
> RETURN
> D type (size 0)
>
> DIF Object 0xffffffff93f31080 (refcnt=3)
>
> ADDR             OPCODE   INSTRUCTION
> ffffffffa1479a20 29010701 ldgs DIF_VAR(107), %r1                ! arg1
> ffffffffa1479a24 23000001 ret  %r1
>
> NAME             ID   KND SCP FLAG TYPE
> arg1             107  scl glb r    D type (size 8)
>
> RETURN
> D type (size 8)
>
> DIF Object 0xffffffff93f31080 (refcnt=3)
>
> ADDR             OPCODE   INSTRUCTION
> ffffffffa1479a20 29010701 ldgs DIF_VAR(107), %r1                ! arg1
> ffffffffa1479a24 23000001 ret  %r1
>
> NAME             ID   KND SCP FLAG TYPE
> arg1             107  scl glb r    D type (size 8)
>
> RETURN
> D type (size 8)
>
> DIF Object 0xffffffff940e8f00 (refcnt=3)
>
> ADDR             OPCODE   INSTRUCTION
> ffffffff921ee700 25000001 setx DIF_INTEGER[0], %r1              ! 0x1
> ffffffff921ee704 28000101 ldga DIF_VAR(0), %r1, %r1
> ffffffff921ee708 22010001 ldx  [%r1], %r1
> ffffffff921ee70c 2a050001 stgs %r1, DIF_VAR(500)                ! iov
> ffffffff921ee710 23000001 ret  %r1
>
> NAME             ID   KND SCP FLAG TYPE
> iov              500  scl glb w    D type (size 8)
>
> RETURN
> D type (size 0)
>
>
> Cheers.
>
> Jon.
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org