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.