Re: [Qemu-devel] [PATCH 1/2] trace: allow trace events with string arguments

[Blue Swirl]

On Tue, Sep 6, 2011 at 2:24 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Mon, Sep 05, 2011 at 07:45:36PM +0000, Blue Swirl wrote:
>> On Mon, Sep 5, 2011 at 3:37 PM, Stefan Hajnoczi
>> <address@hidden> wrote:
>> > String arguments are useful for producing human-readable traces without
>> > post-processing (e.g. stderr backend).  Although the simple backend
>> > cannot handles strings all others can.  Strings should be allowed and
>> > the simple backend can be extended to support them.
>>
>> I don't think this is possible in general. Yes if the string can be
>> found in the executable (assuming address space randomizations don't
>> make that impossible post run), but not if the string happens to be
>> constructed in the stack or in the data segment during run time.
>>
>> So I'd still at least strongly discourage string use.
>
> I don't like strings either because they introduce variable-length data
> that can be expensive to fetch.

This is still a valid point to discourage their use albeit not so strongly.

>  But it's perfectly doable: stderr and
> ust are in-process tracers that have easy access to the string no matter
> where it is located in memory.  In SystemTap you only have the char*
> argument but can use the userspace string copy-in function to fetch the
> actual string (again, no matter where it lives in the process' address
> space).
>
> If your primary trace backend is stderr or ust it makes sense to use
> them.  If you use SystemTap or simpletrace where it is relatively easy
> to do post-processing, then it's lighter weight and nicer (IMO) to
> record just the address and leave pretty-printing to a post-processing
> step.
>
> We can add string support to simpletrace by creating a new file format
> version (or moving to a standarized trace file format).  The format
> needs to support variable-length trace records, which the current format
> cannot support.  Then tracetool can detect char* type arguments and add
> strcpy code into the generated trace_*().
>
> Anyway, tracing should be an aid to developers and users.  It should
> make USB development easier for Gerd.  We need to compete with fprintf
> here :).

It was pretty easy to avoid most uses of strings for those DPRINTF
conversions that I have made. The benefits of tracing aren't in the
replacement process (or even development ease), but actual use of the
trace points. There fprintf can't compete.

> I don't think there is a technical reason why strings are not possible,
> it turns out only simpletrace can't do them and that's my fault.

Nobody came up with a better design at that time, so it was the state
of the art. Maybe it still is since you plan to improve it instead of
scrapping.