From: "Andreas Färber" <afaerber@suse.de>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
Igor Mitsyanko <i.mitsyanko@samsung.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] Configure option to turn on all debug printerfy
Date: Wed, 31 Oct 2012 04:22:10 +0100 [thread overview]
Message-ID: <50909962.2050009@suse.de> (raw)
In-Reply-To: <CAEgOgz6p9QKjcoPzHM10zxu-ybUz2oRShsOuPPWE7W-wprJX2g@mail.gmail.com>
Am 31.10.2012 04:10, schrieb Peter Crosthwaite:
> So in a couple of cases now I have done work on mature device models
> that include #ifdef'd debug printfery that is broken, and have
> submitted (trivial) patches to fix. Whats happening is tree wide or
> automated changes (changing types of variables etc) is causing the
> debug printfery to break, usually werror issues on %x in printfs due
> to types. Issue is, it never gets detected until someone tries to use
> the debug mode: ./configure --extra-cflags="-DFOO_DEBUG". Can we have
> some sort of alternate symbol "ALL_DEBUG" or something, such that
> every debug printf is compiled? Then when developers make tree wide
> changes they can at least compile test for breakages in debug printfs
> using ./configure --extra-cflags="-DALL_DEBUG"? It would be fairly
> trivial to implement.
The original idea I thought was to replace all the DPRINTFs by tracing...
An alternative might be to change the definition from empty DPRINTF(...)
to DPRINTF(...) if (0) { ... }. Then no ALL_DEBUG symbol would be
needed. I don't think anyone would like to get flooded with ALL_DEBUG!
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-10-31 3:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 3:10 [Qemu-devel] [RFC] Configure option to turn on all debug printerfy Peter Crosthwaite
2012-10-31 3:22 ` Andreas Färber [this message]
2012-10-31 4:13 ` Peter Crosthwaite
2012-10-31 9:29 ` Igor Mitsyanko
2012-10-31 9:40 ` Igor Mitsyanko
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=50909962.2050009@suse.de \
--to=afaerber@suse.de \
--cc=i.mitsyanko@samsung.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).