All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mitsyanko <i.mitsyanko@samsung.com>
To: i.mitsyanko@samsung.com
Cc: "Kyungmin Park" <kyungmin.park@samsung.com>,
	"Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC] Configure option to turn on all debug printerfy
Date: Wed, 31 Oct 2012 13:40:28 +0400	[thread overview]
Message-ID: <5090F20C.40306@samsung.com> (raw)
In-Reply-To: <5090EF8A.3030804@samsung.com>


On 10/31/2012 01:29 PM, Igor Mitsyanko wrote:
>
> On 10/31/2012 07:10 AM, Peter Crosthwaite wrote:
>> 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.
>>
>> Regards,
>> Peter
>>
>
> Agree, I think majority of device-specific debugging was broken after 
> ARM physical address length was changed to
> 64 bit. Of course, no one would want to run QEMU with ALL_DEBUG, but I 
> think no one wants to configure QEMU with --target-list=all either, but
> sometimes we have to)
>
> But touching every device could be too invasive, maybe add new target 
> to QEMU makefile "make compile-test", and ask for every new 
> contributor to
> manually add his debug define in some kind of list of defines for 
> "make compile-test".
>

Or maybe just using TARGET_FMT_plx & co should be enough.

-- 
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: i.mitsyanko@samsung.com

      reply	other threads:[~2012-10-31  9:40 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
2012-10-31  4:13   ` Peter Crosthwaite
2012-10-31  9:29 ` Igor Mitsyanko
2012-10-31  9:40   ` Igor Mitsyanko [this message]

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=5090F20C.40306@samsung.com \
    --to=i.mitsyanko@samsung.com \
    --cc=afaerber@suse.de \
    --cc=kyungmin.park@samsung.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.