[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.
[...]