qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 1/2] trace: allow trace events with string arguments
Date: Tue, 6 Sep 2011 15:24:09 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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.  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 :).

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.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]