Re: [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code

[Peter Maydell]

On 4 April 2012 21:34, Blue Swirl <address@hidden> wrote:
> On Wed, Apr 4, 2012 at 20:11, Peter Maydell <address@hidden> wrote:
>> I'd much rather enable a #define to turn on debugging than faff about
>> with tracing. It's simple and straightforward, you can do it with a
>> single obvious change and recompile, and nobody has to look up
>> documentation to figure out how it works.
>
> Laziness. Even the built in help should be sufficient to start using
> tracepoints.

Well, I looked at the docs and said "this gives me no benefit over
DPRINTF, and why do I have to create a file that explicitly lists
every single event the code I'm interested in has defined, and
the quickstart seems to be recommending something that you have to
postprocess, and generally I dunno what problem this is trying to
solve but it doesn't look like it's trying to solve programmer debug
tracing".

If other people want to write trace events that's fine but for me
at the moment it seems a definite step back from simple DPRINTF
macros.

>> If tracepoints were always-compiled-in and enabled at runtime I'd
>> agree with you: then you could have linux-kernel-style "enable debug
>> tracing", "enable warnings about odd guest behaviour", "be silent",
>> etc. But they're not, so they don't gain anything over a simple
>> DPRINTF for programmer debugging.
>
> False. It's easy to compile in tracepoints
> (--enable-trace-backend=simple) and the overhead is zero or marginal.

(a) that gives you a binary dump rather than something actually
readable (and 'simple' can't even handle string output!) and
(b) if it's that good why don't we enable it by default?
Also I can't see anything in the docs about having sensible sets
of levels of tracing or grouping trace events into coherent sets
you can toggle on and off.

> Processing is offline.

For debugging this is not a feature -- you want to see the output
as you step through things in the debugger.

-- PMM