qemu-s390x
[Top][All Lists]
Advanced

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

Re: [risu PATCH 0/4] Add support for s390x to RISU


From: Ilya Leoshkevich
Subject: Re: [risu PATCH 0/4] Add support for s390x to RISU
Date: Mon, 04 Sep 2023 16:30:34 +0200
User-agent: Evolution 3.48.4 (3.48.4-1.fc38)

On Mon, 2023-09-04 at 16:00 +0200, Thomas Huth wrote:
>  Hi Peter!
> 
> Here are some patches that add basic support for s390x to RISU.
> It's still quite limited, e.g. no support for load/store memory
> operations yet, but the basics with simple 16-bit or 32-bit
> instructions work already fine.
> 
> (In the long run, we'd need to support instructions with 48-bit
> length on s390x, too, since most newer "interesting" instructions
> like e.g. vector SIMD instructions are encoded with 48 bit. This
> will require modifications to the generic code, too, so I limited
> my initial implementation to 16-bit and 32-bit instruction length
> support to keep the code self-contained in the s390x architecture
> specific files)

What's also interesting about SIMD, is that floating-point instructions
clobber the upper parts of vector registers. I wonder if there is a way
to systematically solve this? In my scripts the solution isn't pretty:

            insn = gdb.execute("x/i $pc", to_string=True)
            print(insn)
            gdb.execute("stepi")
            if "%f" in insn:
               [ Skip comparison ]

I think there are also a few cases in non-SIMD areas, where PoP
basically says "if conditions X and Y hold, the output is
unpredictable".


One other thing - for not-so-near future - is it possible to integrate
this with coverage-based fuzzers? I.e., somehow generate the
instructions based on the coverage signal. Maybe even make sure that
the signal comes from JITed code too. I wanted to try AFLplusplus in
QEMU mode for this purpose (which would ultimately run QEMU in QEMU),
but never found the time.

[...]



reply via email to

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