On 5/23/22 05:15, Thomas Huth wrote:
On 19/05/2022 13.41, Peter Maydell wrote:
On Mon, 16 May 2022 at 16:22, Thomas Huth <th...@redhat.com> wrote:
Now that we allow compiling with Capstone v3.05 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we do not need to ship this as a submodule anymore.
When this eventually goes in, please remember to update the
wiki changelog page's 'Build Information' section to let
users know.
Done: https://wiki.qemu.org/ChangeLog/7.1#Build_Dependencies
Ho hum. So... the first time I try to do any actual debugging after this has gone in, and
I am reminded exactly how terrible capstone 4.0.1 is for anything except x86. There was a
reason I had chosen a development branch snapshot, and that's because it was usable.
Here, for instance, is how ubuntu 20.04 capstone disassembles
tests/tcg/aarch64/system/boot.S:
0x00000000400027b0: 10ffc280 adr x0, #-0x7b0 (addr 0x40002000)
0x00000000400027b4: d518c000 msr (unknown), x0
0x00000000400027b8: d0000fe0 adrp x0, #+0x1fe000 (addr 0x40200000)
0x00000000400027bc: 91000000 add x0, x0, #0x0 (0)
0x00000000400027c0: d5182000 msr (unknown), x0
...
0x0000000040002850: d5381040 mrs x0, (unknown)
0x0000000040002854: b26c0400 orr x0, x0, #0x300000
0x0000000040002858: d5181040 msr (unknown), x0
And this is the extremely simple case of ARMv8.0 with no extensions.
I am very much tempted to re-instate the capstone submodule, or update disas/vixl and
disable use of capstone for arm.
Would the ppc folk please have a look at how capstone is or is not handling ppc64?
Because I strongly suspect that 333f944c15e7 ("disas: Remove old libopcode ppc
disassembler") is also going to turn out to be a regression when combined with the removal
of the capstone submodule.
r~
PS: While there are tags in upstream capstone hinting at a 5.0 release, there's no
timeline for when we might see such a thing. Anyway, it wouldn't help anyone with an LTS
distro for the next half decade.
