qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 3/3] target/mips: Add disassembler support for na


From: Stefan Weil
Subject: Re: [Qemu-devel] [PULL 3/3] target/mips: Add disassembler support for nanoMIPS
Date: Tue, 27 Nov 2018 13:27:48 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

Am 27.11.2018 um 12:24 schrieb Peter Maydell:
> On Thu, 8 Nov 2018 at 08:00, Stefan Weil <address@hidden> wrote:
>> On 25.10.18 22:19, Aleksandar Markovic wrote:
>>> From: Aleksandar Markovic <address@hidden>
>>>
>>> Add disassembler support for nanoMIPS.
>>>
>>> Reviewed-by: Stefan Markovic <address@hidden>
>>> Signed-off-by: Matthew Fortune <address@hidden>
>>> Signed-off-by: Aleksandar Markovic <address@hidden>
>>> ---
>>>  MAINTAINERS           |     2 +
>>>  configure             |     3 +
>>>  disas/Makefile.objs   |     1 +
>>>  disas/nanomips.cpp    | 22242 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>  disas/nanomips.h      |  1099 +++
>>>  include/disas/bfd.h   |     1 +
>>>  include/exec/poison.h |     1 +
>>>  target/mips/cpu.c     |    13 +-
>>>  8 files changed, 23360 insertions(+), 2 deletions(-)
>>>  create mode 100644 disas/nanomips.cpp
>>>  create mode 100644 disas/nanomips.h
>>
>> Hi,
>>
>> the disassembler needs more work for the next QEMU release: it uses lots
>> of wrong format strings which will result in wrong output at least on
>> big endian hosts.
> Hi Stefan; by "for the next QEMU release" do you mean:
> (a) this is a release-critical bug which we need to fix for 3.1
> (b) this is not critical for this release, but we should
> fix it in the next release (4.0)
>
> ?
>
> thanks
> -- PMM


Hi Peter,

the fix is rather trivial. That's why I now have sent a patch series.

I'm not sure whether it should be handled as "release-critical". Big
endian Linux distributions would have a problem if users use nanomips
with the disassembler: I expect that numbers in the disassembler output
would be completely wrong.

There would be no crash, and I don't think that use case is very common,
so maybe a fix which avoids using 64 bit data types as suggested by
Aleksandar could be postponed until 4.0.

If you think that a fix for 3.1 would be better, you can use my fix. It
is also used in my builds for Windows.

Regards
Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]