qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] trace: allow trace events with string arguments
Date: Tue, 6 Sep 2011 15:24:09 +0100	[thread overview]
Message-ID: <20110906142409.GB27870@stefanha-thinkpad.localdomain> (raw)
In-Reply-To: <CAAu8pHsU=B-JL2Np6TJqOtJgsSD1RR=76mrNazkuo2k3BZNfxQ@mail.gmail.com>

On Mon, Sep 05, 2011 at 07:45:36PM +0000, Blue Swirl wrote:
> On Mon, Sep 5, 2011 at 3:37 PM, Stefan Hajnoczi
> <stefanha@linux.vnet.ibm.com> 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

  parent reply	other threads:[~2011-09-06 14:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-05 15:37 [Qemu-devel] [PATCH 1/2] trace: allow trace events with string arguments Stefan Hajnoczi
2011-09-05 15:37 ` [Qemu-devel] [PATCH 2/2] MAINTAINERS: add tracing subsystem Stefan Hajnoczi
2011-09-05 19:45 ` [Qemu-devel] [PATCH 1/2] trace: allow trace events with string arguments Blue Swirl
2011-09-05 21:17   ` Jan Kiszka
2011-09-06 14:24   ` Stefan Hajnoczi [this message]
2011-09-07 19:21     ` Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110906142409.GB27870@stefanha-thinkpad.localdomain \
    --to=stefanha@gmail.com \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).