Re: [RFC] Collecting strings at tracepoints

[Doug Evans <dje@google.com>]

On Fri, Jun 4, 2010 at 3:52 PM, Stan Shebs <stan@codesourcery.com> 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.

Apologies for coming into this a bit late.

I want to make sure I understand the proposed syntax.

str@@ would collect up to the first \0 or print elements limit.
str@/80 would collect up to the first \0 or 80 bytes.

That feels too inconsistent: "@@" triggers the special "up until the
first \0", *except* when its @/.
"up until the first \0" is one thing and specifying a limit is an
add-on.  Each should have their own syntax (e.g. str@@/80; it's
perhaps klunkier, but @@ is klunky to begin with. :-)]

Michael mentioned collect /s as a possibility.
That *feels* better, given that you mention the print command (if p/s
doesn't print its arg as a string, what does p/s mean?).
To add a max-length, "collect /80s" doesn't work, it's inconsistent
with the "x" command; "x /80s" doesn't mean "max 80 chars".
Maybe "collect /s@80"?  [At this point, I don't have a strong opinion
on @ vs another character.]
"x/s@80 foo" feels like a nice extension (print foo as a string up to 80 chars)
Plus "x/20s@80 foo" also works (print 20 strings beginning at foo,
each with a max length of 80).