Re: [Qemu-devel] [PATCH] target-lm32: fix style issue

[Peter Maydell]

On 12 October 2016 at 18:11, Michael Walle <address@hidden> wrote:
> Am 2016-10-12 18:35, schrieb Peter Maydell:
>> but I noticed while doing the review that our LOG_DIS
>> is wrong for the compare-immediates:
>>
>>         LOG_DIS("cmpei r%d, r%d, %d\n", dc->r0, dc->r1,
>>                 sign_extend(dc->imm16, 16));
>>
>> but the processor reference manual says cmpei's mnemonic
>> should have dc->r1 first and dc->r0 second.

> can I drop the DISAS_LM32 macro and just always enable the
> qemu_log_mask(CPU_LOG_TB_IN_ASM)? Looking at other CPUs this is sometimes a
> (debug) compile switch (eg ppc) and sometimes its always enabled (tilegx).

tilegx unconditionally does this logging because there's
no tilegx disassembler in disas/, and so printing log
statements in the decoder is a dubious but low effort way
to achieve the desired effect (that -d in_asm prints the
guest disassembly).

ppc on the other hand has a proper disassembler in disas/,
and so the LOG_DISAS() stuff is just debug-printf stuff
for the purposes of tracking down bugs in the decoder,
and like most of the debug-printf macros in devices it
is not compiled in by default (you turn it on by hand if
you have a bug it might help with), and exactly what is
logged is very much ad-hoc.

But lm32 has a disassembler in disas, so it doesn't need
to emit this stuff for -d in_asm to work, and indeed shouldn't
emit it by default, otherwise all the disassembly would be
printed twice. You can see this bug if you do:

./build/x86-all/lm32-softmmu/qemu-system-lm32  -d in_asm -D
/tmp/lm32.log -M milkymist -serial stdio -kernel
~/test-images/milkymist/flickernoise

as the resulting log looks like:

40000000:       98000000        xor r0, r0, r0
40000004:       d0000000        wcsr r0, 0

0x40000000:  98 00 00 00    xor      r0, r0, r0
0x40000004:  d0 00 00 00    wcsr     ie, r0

isize=8 osize=11
40000008:       d0200000        wcsr r0, 1

0x40000008:  d0 20 00 00    wcsr     im, r0

isize=4 osize=9
4000000c:       78014000        mvhi r1, 16384
40000010:       38210000        ori r1, r1, 0
40000014:       d0e10000        wcsr r1, 7
40000018:       e000003a        bi 232

0x4000000c:  78 01 40 00    orhi     r1, r0, 0x4000
0x40000010:  38 21 00 00    ori      r1, r1, 0x0
0x40000014:  d0 e1 00 00    wcsr     eba, r1
0x40000018:  e0 00 00 3a    bi       40000100

mixing the disassembly from the disassembler
with the debug output from the translate.c code in
a somewhat confusing way.

thanks
-- PMM