You have a couple different things in play here.
First, MDB pipelines only work with uintptr_t's, not arbitrary text. So
when you try to pipe something like "foo: X" or "X Y Z" to another dcmd,
the parser will choke.
Normally, the formatting commands ('/' and friends) recognize when you
are in pipe context and omit any extraneous formatting characters.
Since they only output numbers, they are safe to use in pipe context.
However, under ::eval, any notion of pipe context is (intentionally)
ignored. So ::eval '/Kn' will print the extra formatting characters
(such as "swap_vnodes:") as it has no way of knowing it's being used in
pipe context outside the eval context. One way to get around this is to
do something like:
::array ... p | ::eval '<p/Kn | =Kn' | ::grep .==0
That being said, for this particular case you do not need the '::eval
<p' at all, since it's identical to the output from '::array'.
- Eric
On Fri, Aug 24, 2007 at 11:29:01PM +0800, zhijun wrote:
>
> While I still have some doublt for my second question, in which,
> fffffffecc47e000::array "struct vnode *" 0t2048 p|::eval <p/K|::grep
> .==0 doesn't work.
>
> > swap_vnodes/K
> swap_vnodes:
> swap_vnodes: fffffffecb5bc000
>
> > fffffffecb5bc000::array "struct vnode *" 10
> fffffffecb5bc000
> fffffffecb5bc008
> fffffffecb5bc010
> fffffffecb5bc018
> fffffffecb5bc020
> fffffffecb5bc028
> fffffffecb5bc030
> fffffffecb5bc038
> fffffffecb5bc040
> fffffffecb5bc048
> fffffffecb5bc050
> fffffffecb5bc058
> fffffffecb5bc060
> fffffffecb5bc068
> fffffffecb5bc070
> fffffffecb5bc078
>
> Use ::grep pipelined with ::eval<p=K can work while with ::eval <p/K
> doesn't work
>
> > fffffffecb5bc000::array "struct vnode *" 10 p|::eval <p=K|::grep
> .==0 /* this works */
> > fffffffecb5bc000::array "struct vnode *" 10 p|::eval <p/K|::grep
> .==0 /* this doesn't work */
> mdb: syntax error on line 1 of (pipeline) near ":"
>
> > fffffffecb5bc000::array "struct vnode *" 10 p|::eval <p=K
> fffffffecb5bc000
> fffffffecb5bc008
> fffffffecb5bc010
> fffffffecb5bc018
> fffffffecb5bc020
> fffffffecb5bc028
> fffffffecb5bc030
> fffffffecb5bc038
> fffffffecb5bc040
> fffffffecb5bc048
> fffffffecb5bc050
> fffffffecb5bc058
> fffffffecb5bc060
> fffffffecb5bc068
> fffffffecb5bc070
> fffffffecb5bc078
> > fffffffecb5bc000::array "struct vnode *" 10 p|::eval <p/K
> 0xfffffffecb5bc000: 0
> 0xfffffffecb5bc008: 0
> 0xfffffffecb5bc010: 0
> 0xfffffffecb5bc018: 0
> 0xfffffffecb5bc020: 0
> 0xfffffffecb5bc028: 0
> 0xfffffffecb5bc030: 0
> 0xfffffffecb5bc038: 0
> 0xfffffffecb5bc040: 0
> 0xfffffffecb5bc048: 0
> 0xfffffffecb5bc050: 0
> 0xfffffffecb5bc058: 0
> 0xfffffffecb5bc060: 0
> 0xfffffffecb5bc068: 0
> 0xfffffffecb5bc070: 0
> 0xfffffffecb5bc078: 0
>
> Looking at the above output, I guess the reason is the output format, I
> checked "Solaris Modular Debugger Guide" and on page 32 it says each
> line in the output before '|' must consist of an arithmetic expression
> terminated by a NEWLINE or semicolon. So it seems that the reason here
> is that the output of ::eval <p=K doesn't conform to this thus breaks
> the pipeline of dcmds. But let's look at the output of /Kn
>
> > fffffffecb5bc000::array "struct vnode *" 10 |/Kn
> 0xfffffffecb5bc000: 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> > fffffffecb5bc000::array "struct vnode *" 10 |/Kn|::grep .==0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
>
> My two questions here:
> While /n is added to make sure each expression occupies one line, here
> the first line does not exactly consist of an arithmetic expression, and
> it contains the address of the first entry in array, so I would expect
> it will break the pineline, but instead, it works fine. I am somehow
> puzzled about this. Could you give me some hint on this?
> Another question is why the output of /Kn and ::eval <p/K are different?
> Basically I think the output should be the same as they each takes an
> address and dump the content one line a time.
>
> Thanks again,
> Zhijun
>
>
>
>
> _______________________________________________
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
