On Mon, Mar 09, 2009 at 12:05:37PM -0400, James Carlson wrote:
> I've gone through the materials, and I have one question about the new
> behavior for ::print: how does it disambiguate the command line?
>
> For example, if I do this:
>
> > ::walk foo | ::print bar
>
> is "bar" a member of whatever sort of structure the "foo" list
> contains, or is "bar" the type of object I want to print in its
> entirety?
It builds upon the (possibly broken) current behavior:
1. if "bar" resolves as a type, we use that, or
2.* if there's a valid pipe type, we use that, or
3. if addr is a symbol with associated type info, we use that.
(* is the new behavior). This, unfortunately, has the DWIM nature, and
there's no current way to disambiguate it.
> Suppose I really do want to print all of kthread_t in the example you
> gave above. What would this do?
>
> ::walk thread | ::print kthread_t
>
> Is that now an error because kthread_t is a member of the kthread_t
> structure?
No; you can (and I believe should be able to) override the type. This
will print the addresses as a kthread structure.
> I can see how I'd use this if both the data type and the member are
> present, but I'm not sure what the new command does when there's just
> one token.
>
> Perhaps what's needed is a new summary for ::print -- the command line
> in the documentation (though oddly not the ::help text) says this:
>
> [address] ::print [-aCdiLptx] [-c lim] [-l lim] [type [member|offset ... ]]
>
> ... but that strict [type [member]] nesting (meaning that "type" is
> always present when "member" is present) is no longer true.
It was always kind of funky (see #3, above). Perhaps we need a couple more
options:
Usage: [addr] ::print [-aCdhiLnptx] [-c lim] [-l lim] [-s depth]
[[type] [member|offset...]] [ | ::dcmd ...]
[addr] ::print [-aCdhiLnptx] [-c lim] [-l lim] [-s depth]
-T type [member|offset...] [ | ::dcmd ...]
[addr] ::print [-aCdhiLnptx] [-c lim] [-l lim] [-s depth]
-I [member|offset...] [ | ::dcmd ...]
Where either -T type or -I remove the "type" argument, and either specify the
type or make inference required.
Of course, to do that, I'd have to go ahead and implement the "multiple usage"
DCMD usage strings I've been meaning to do...
Cheers,
- jonathan
