Re: [Qemu-devel] [PULL 10/25] aarch64-linux-user: Add support for SVE signal frame records

[Peter Maydell]

On 6 April 2018 at 19:12, Peter Maydell <address@hidden> wrote:
> On 9 March 2018 at 17:26, Peter Maydell <address@hidden> wrote:
>> From: Richard Henderson <address@hidden>
>>
>> Depending on the currently selected size of the SVE vector registers,
>> we can either store the data within the "standard" allocation, or we
>> may beedn to allocate additional space with an EXTRA record.
>>
>> Signed-off-by: Richard Henderson <address@hidden>
>> Message-id: address@hidden
>> Reviewed-by: Peter Maydell <address@hidden>
>> Signed-off-by: Peter Maydell <address@hidden>
>> ---
>>  linux-user/signal.c | 210 
>> +++++++++++++++++++++++++++++++++++++++++++++++-----
>>  1 file changed, 192 insertions(+), 18 deletions(-)
>
> I did a 'git bisect' looking for when we introduced the segv
> bug described in https://bugs.launchpad.net/qemu/+bug/1761535,
> and git bisect thinks this commit is it.
>
> At least for me, with a xenial aarch64 chroot, with this
> patch if I chroot in and run 'ls' then we get a spurious
> segfault (I think in the guest bash):
>
> e104462:xenial:chroot$ sudo chroot xenial-aarch64
> address@hidden:/# ls
> Deadlock.class    bin   home                  hotspot_pid17113.log
> mnt   root   srv  var
> Deadlock.java     boot  hotspot_pid14759.log  hotspot_pid19407.log
> opt   run    sys
> HelloWorld.class  dev   hotspot_pid16542.log  lib
> proc  sbin   tmp
> HelloWorld.java   etc   hotspot_pid16895.log  media
> risu  sdbg9  usr
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault (core dumped)
>
> Reverting f914baef8e39f7 on master fixes the segfault.

Er, I mean "reverting 8c5931de0ac77388096d79c". Accidentally quoted
the git hash of the local revert-commit I was testing rather than
of the commit it's reverting...

thanks
-- PMM