RFC on bug #3672: pretty printing compound types

RFC on bug #3672: pretty printing compound types

[Josh Stone]

http://sourceware.org/bugzilla/show_bug.cgi?id=3672

I just pushed commit 5f36109e to add initial support for this feature,
and I was promptly told that my syntax and semantics are kooky.  I can't
really deny that, but I tried to clarify it in comment #10.

Of course it is subject to change, at least until the next release.  I
just wanted to get something concrete out there sooner rather than
later.  So please take a look, and feel free to ask for more
clarification and suggest modifications.

Thanks,

Josh

Re: RFC on bug #3672: pretty printing compound types

[Roland McGrath]

It's wonderful to see this feature taking shape.  Everyone wants it.

Your commit notably lacks any documentation additions.  I think we'll find
it easier to debate the merits of syntax and arcane details of the semantics
if we have a full description of the syntaxes and their meaning to start with.


Thanks,
Roland

Re: RFC on bug #3672: pretty printing compound types

[Josh Stone]

On 05/27/2010 07:36 PM, Roland McGrath wrote:
> It's wonderful to see this feature taking shape.  Everyone wants it.
> 
> Your commit notably lacks any documentation additions.  I think we'll find
> it easier to debate the merits of syntax and arcane details of the semantics
> if we have a full description of the syntaxes and their meaning to start with.

Typical lazy programmers... oh wait, that's me.  Well here's a bit then:


A new '$' suffix can be used to create a formatted string for complex
variable types.  This will print each member name and value of structs
and classes.  The suffix is valid on both $var and @cast() forms of
variable access, and can be used either directly ($var$) or with the
arrow notation ($var->$) with the same meaning.

The result string will recurse into any struct-typed members as well,
but pointers and references will just be printed as a memory address.
To traverse even further through pointers, the suffix may be repeated:
"$var$$" to print all of $var including one level of pointers, "$var$$$"
for an additional level still, etc.

Here are some examples of the resulting format string, which would have
the values filled in at runtime:

struct timeval:
"{.tv_sec=%i, .tv_usec=%i}"

struct itimerval:
"{.it_interval={.tv_sec=%i, .tv_usec=%i}, .it_value={.tv_sec=%i,
.tv_usec=%i}}"

struct fs_struct:
"{.users=%i, .lock={.raw_lock={.lock=%u}}, .umask=%i, .in_exec=%i,
.root={.mnt=%p, .dentry=%p}, .pwd={.mnt=%p, .dentry=%p}}"

stap's struct token:
"{.location={.file=%p, .line=%u, .column=%u}, .type=%i,
.content={._M_dataplus={._M_p=%p}}}"
// .content is an std::string - I'm planning to make this nicer...


Here's an example using stap-on-stap:

$ cat target_symbol_loc.stp
probe process("stap").function("*::visit_target_symbol") {
  printf("%s  %s\n", $e->tok->location$, probefunc())
}
$ stap target_symbol_loc.stp -c 'stap -l kprocess.release'
kprocess.release
{.file=0x0000000001297cb0, .line=113, .column=12}
deep_copy_visitor::visit_target_symbol
{.file=0x0000000001297cb0, .line=113, .column=12}
update_visitor::visit_target_symbol
{.file=0x0000000001297cb0, .line=114, .column=11}
deep_copy_visitor::visit_target_symbol
{.file=0x0000000001297cb0, .line=114, .column=11}
update_visitor::visit_target_symbol
{.file=0x0000000001297cb0, .line=113, .column=12}
dwarf_var_expanding_visitor::visit_target_symbol
{.file=0x0000000001297cb0, .line=114, .column=11}
dwarf_var_expanding_visitor::visit_target_symbol

(Sorry for the mail wordwrap - it looks much nicer on a wide terminal, I
promise...)


From the comments I've gotten, I think I'll probably forget the ->$
syntax.  The other idea that I'm favoring is to stop following pointers,
and just make "$" print the structure without any substructures and "$$"
print with all substructures.  But more opinions are welcome, please.

Thanks,
Josh

Re: RFC on bug #3672: pretty printing compound types

[Frank Ch. Eigler]

Josh Stone <jistone@redhat.com> writes:

> [...]
> struct fs_struct:
> "{.users=%i, .lock={.raw_lock={.lock=%u}}, .umask=%i, .in_exec=%i,
> .root={.mnt=%p, .dentry=%p}, .pwd={.mnt=%p, .dentry=%p}}"

I like the automatic selection of %i/%u/%p.  We should do the same
thing for $$parms and siblings.


> [...]  The other idea that I'm favoring is to stop following
> pointers, and just make "$" print the structure without any
> substructures and "$$" print with all substructures.  [...]

In that case, we'd have no primitive for following generic pointers,
right?  So one would have to hand-write scripts like these in order to
draw to pointed-to structures.

# probe process("stap").function("*::visit_target_symbol")
#   printf("%s  %s\n", $e$, probefunc())
or 
#   printf("%s  %s\n", $e->tok$, probefunc())

That seems unfortunate.  Maybe use your arrow notation to indicate
pointer-dereferenced pretty-printing?

    $e->->$   for two levels of pointer dereferncing?


- FChE

Re: RFC on bug #3672: pretty printing compound types

[Josh Stone]

On 05/28/2010 06:33 PM, Frank Ch. Eigler wrote:
>> [...]  The other idea that I'm favoring is to stop following
>> pointers, and just make "$" print the structure without any
>> substructures and "$$" print with all substructures.  [...]
> 
> In that case, we'd have no primitive for following generic pointers,
> right?  So one would have to hand-write scripts like these in order to
> draw to pointed-to structures.
> 
> # probe process("stap").function("*::visit_target_symbol")
> #   printf("%s  %s\n", $e$, probefunc())
> or 
> #   printf("%s  %s\n", $e->tok$, probefunc())
> 
> That seems unfortunate.  Maybe use your arrow notation to indicate
> pointer-dereferenced pretty-printing?
> 
>     $e->->$   for two levels of pointer dereferncing?

It quickly blows up in size when you traverse pointers though, and we're
limited to MAXSTRINGLEN.  I have no generic way to know that ->tok is
the only pointer you care about, so all the other pointers in the
structure get expanded too.

Would it be ok if I just make the suggested change now, and then later
we can consider introducing the arrow notation to expand further?


Josh