[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v2 02/15] target-ppc: Move PPC_DUMP_CPU to transla
From: |
Andreas Färber |
Subject: |
Re: [Qemu-ppc] [PATCH v2 02/15] target-ppc: Move PPC_DUMP_CPU to translate.c |
Date: |
Mon, 25 Feb 2013 15:28:20 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 |
Am 25.02.2013 14:48, schrieb Alexander Graf:
>
> On 25.02.2013, at 14:02, Andreas Färber wrote:
>
>> Am 25.02.2013 13:49, schrieb Alexander Graf:
>>>
>>> On 21.02.2013, at 05:24, Andreas Färber wrote:
>>>
>>>> There's an opcode handler field dependent on PPC_DUMP_CPU without which
>>>> the build fails.
>>>>
>>>> Signed-off-by: Andreas Färber <address@hidden>
>>>> ---
>>>> target-ppc/translate.c | 1 +
>>>> target-ppc/translate_init.c | 1 -
>>>> 2 Dateien geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
>>>>
>>>> diff --git a/target-ppc/translate.c b/target-ppc/translate.c
>>>> index 2ac5794..2e74e45 100644
>>>> --- a/target-ppc/translate.c
>>>> +++ b/target-ppc/translate.c
>>>> @@ -33,6 +33,7 @@
>>>>
>>>> /* Include definitions for instructions classes and implementations flags
>>>> */
>>>> //#define PPC_DEBUG_DISAS
>>>> +#undef PPC_DUMP_CPU
>>>
>>> #undef?
>>
>> // is not permitted. :)
>> Alternative would be /* #define ... */
>>
>> Just edit the line to your liking. :)
>
> The current coding style for debug defines is // #define DEBUG_FOO. It don't
> think it makes sense to deviate from that notion unless we do it
> consistently. And to do that, we need to consistentify the handling first
> which your patches do.
Having gone through all targets I can guarantee you there is no
consistent style ATM: ppc and other pre-checkpatch.pl targets use
//#define ...; s390x uses /* #define ... */ and some others use #undef
..., the latter being less typing both for me and for enabling.
So if you dislike #undef, I suggest you edit it as //#define.
> So IMHO I'd rather like to see a patch changing the style to whatever people
> prefer after this set is through.
Feel free to send one... :-)
BTW generally I would rather see the relevant ..._DUMP_... data exposed
as QOM properties on the CPU object; that would allow to inspect data on
demand rather than dumping a whole bunch always-or-never. But I have
doubts about exposing the current fields 1:1 - we'd have to decide on
sensible property names and values then.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-ppc] [PATCH v2 00/15] Debug output revamp, Richard Henderson, 2013/02/21
- Re: [Qemu-ppc] [PATCH v2 00/15] Debug output revamp, Paolo Bonzini, 2013/02/21
- Re: [Qemu-ppc] [PATCH v2 00/15] Debug output revamp, Andreas Färber, 2013/02/21
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Markus Armbruster, 2013/02/22
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Andreas Färber, 2013/02/22
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Richard Henderson, 2013/02/22
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Markus Armbruster, 2013/02/22
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Andreas Färber, 2013/02/22
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Peter Crosthwaite, 2013/02/23
- Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 00/15] Debug output revamp, Alexander Graf, 2013/02/25