[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