On 6/23/19 7:10 PM, Aleksandar Markovic wrote:
> On Sat, Jun 22, 2019 at 5:02 PM Mark Cave-Ayland
> <mark.cave-ayl...@ilande.co.uk> wrote:
>>
>> On 22/06/2019 15:20, Mark Cave-Ayland wrote:
>>
>>> I've just given your tcg-ppc-vsx branch a spin here, and like Howard I'm
>>> getting
>>> segfaults trying to launch my MacOS images :( The segfault is weird: it
>>> doesn't get
>>> caught by an attached gdb and the qemu-system-ppc process seems to hang
>>> around like a
>>> zombie which makes me think that it's probably an illegal instruction of
>>> some kind,
>>> but the PPC kernel can't handle it as well as x86 does.
>>>
>>> With a bit more work I bisected it down to the first commit in the patchset
>>> (d8dcbb57e9: "tcg/ppc: Initial backend support for Altivec") and then as an
>>> experiment I hacked tcg_can_emit_vec_op() to always return 0 to see if that
>>> made a
>>> difference, but the segfault still appears.
>>>
>>> The commit message mentions that the load and store helpers are also
>>> improved, so I
>>> wonder if they are what is causing the error rather than the vector parts?
>>> Also in
>>> the kernel log I see the following messages appearing:
>>>
>>> [3639669.374942] qemu-system-ppc[28591]: segfault (11) at 64b8 nip f87280
>>> lr f8723c
>>> code 1 in qemu-system-ppc[94e000+aa0000]
>>> [3639669.380015] qemu-system-ppc[28591]: code: 93c10038 91810020 90010044
>>> 7fc802a6
>>> 3fde0059 2e030000 3bde6c18 7c9d2378
>>> [3639669.385056] qemu-system-ppc[28591]: code: 813e80a0 7cbb2b78 7cda3378
>>> 7cf93b78
>>> <81428ff8> 9141001c 39400000 81290000
>>>
>>> Does that help at all? If not let me know if there are any other tests that
>>> you'd
>>> like me to try to help debug this.
>>
>> One more hint: if I try a build of d8dcbb57e9 along with my
>> tcg_can_emit_vec_op()
>> hack and pass --enable-debug-tcg to configure then I get an assert on
>> startup:
>>
>> qemu-system-ppc: /home/mca/src/qemu/tcg/tcg.c:2207: process_op_defs:
>> Assertion `tdefs
>> != ((void *)0)' failed.
>> Aborted
>>
>
> Mark, Richard, Howard, David,
>
> I just sent v5 of the series, that is (in the sense of net-result of
> code changes) equivalent to v4, but the patch 1/7 from v4 is now split
> into ten smaller patches. This was done mainly to enable Mark to
> perhaps try v5 and bisect, in order to at least somewhat narrow down
> the culprit. Most likely it will be patch 5 from v5, that is still
> sizeable, but even if this is the case, we can eliminate other smaller
> things from consideration.
Thanks for the help on that.
I don't believe your split is actually bisectable -- there's a minimum amount
that is required to enable vector opcodes at all. Patch 5 is the first that
enables tcg_out_{mov,ld,st}, so while patches beforehand may compile, they
certainly will not run.
I can retain your split, but for real bisectability we need to move the enable
of TCG_TARGET_HAS_v128 from patch 2 to patch 5.
Given that all this works for me on a Power9 host, I expect that there's a
simple fix for Mark's G5 host. Given the above assertion, a missing opcode
definition, perhaps for -m32 vs -m64?
r~
