Re: [RFC] Collecting strings at tracepoints

[Michael Snyder <msnyder at vmware dot com>]

Stan Shebs wrote:
> Collection of strings is a problem for tracepoint users, because the 
> literal interpretation of "collect str", where str is a char *, is to 
> collect the address of the string, but not any of its contents.  It is 
> possible to use the '@' syntax to get some contents, for instance 
> "collect str@40" acquires the first 40 characters, but it is a poor 
> approximation; if the string is shorter than that, you collect more than 
> necessary, and possibly run into access trouble if str+40 is outside the 
> program's address space, or else the string is longer, in which case you 
> may miss the part you really wanted.
>
> For normal printing of strings GDB has a couple tricks it does.  First, 
> it explicitly recognizes types that are pointers to chars, and 
> automatically dereferences and prints the bytes it finds.  Second, the 
> print elements limit prevents excessive output in case the string is long.
>
> For tracepoint collection, I think the automatic heuristic is probably 
> not a good idea.  In interactive use, if you print too much string, or 
> just wanted to see the address, there's no harm in displaying extra 
> data.  But for tracing, the user needs a little more control, so that 
> the buffer doesn't inadvertantly fill up too soon.  So I think that 
> means that we should have the user explicitly request collection of 
> string contents.
>
> Looking at how '@' syntax works, we can extend it without disrupting 
> expression parsing much.  For instance, "str@@" could mean to deference 
> str, and collect bytes until a 0 is seen, or the print elements limit is 
> reached (implication is that we would have to tell the target that 
> number).  The user could exercise even finer control by supplying the 
> limit explicitly, for instance "str@/80" to collect at most 80 chars of 
> the string.  ("str@@80" seems like it would cause ambiguity problems vs 
> "str@@").
>
> This extended syntax could work for the print command too, in lieu of 
> tweaking the print element limit, and for types that GDB does not 
> recognize as a string type.
>
> Under the hood, it's not yet clear if we will need additional bytecodes, 
> but probably so.

Another possibility might be as an option to the "collect" command,
eg.
> collect /s foo (collect foo as a string).

Does seem like an additional byte code would be needed.