target/arm/neon-ls.decode | 4 +-- target/arm/translate.c | 32 +++++++++-------- target/arm/translate-neon.c.inc | 63 +++++++++++++++++++++++++-------- target/arm/translate-vfp.c.inc | 30 ++++++++++------ 4 files changed, 88 insertions(+), 41 deletions(-)
As reported in https://bugs.launchpad.net/bugs/1905356 Not implementing SCTLR.A, but all of the other required alignment for SCTLR.A=0 in Table A3-1. r~ Richard Henderson (11): target/arm: Enforce word alignment for LDRD/STRD target/arm: Enforce alignment for LDA/LDAH/STL/STLH target/arm: Enforce alignment for LDM/STM target/arm: Enforce alignment for RFE target/arm: Enforce alignment for SRS target/arm: Enforce alignment for VLDM/VSTM target/arm: Enforce alignment for VLDR/VSTR target/arm: Enforce alignment for VLD1 (all lanes) target/arm: Enforce alignment for VLDn/VSTn (multiple) target/arm: Fix decode of align in VLDST_single target/arm: Enforce alignment for VLDn/VSTn (single) target/arm/neon-ls.decode | 4 +-- target/arm/translate.c | 32 +++++++++-------- target/arm/translate-neon.c.inc | 63 +++++++++++++++++++++++++-------- target/arm/translate-vfp.c.inc | 30 ++++++++++------ 4 files changed, 88 insertions(+), 41 deletions(-) -- 2.25.1
On Wed, 25 Nov 2020 at 04:06, Richard Henderson <richard.henderson@linaro.org> wrote: > As reported in https://bugs.launchpad.net/bugs/1905356 > > Not implementing SCTLR.A, but all of the other required > alignment for SCTLR.A=0 in Table A3-1. Any particular reason not to also support SCTLR.A ? Also not implementing the old v5 unaligned access behaviour, but we never have done that... Whole series: Reviewed-by: Peter Maydell <peter.maydell@linaro.org> thanks -- PMM
On 12/1/20 8:27 AM, Peter Maydell wrote: > On Wed, 25 Nov 2020 at 04:06, Richard Henderson > <richard.henderson@linaro.org> wrote: >> As reported in https://bugs.launchpad.net/bugs/1905356 >> >> Not implementing SCTLR.A, but all of the other required >> alignment for SCTLR.A=0 in Table A3-1. > > Any particular reason not to also support SCTLR.A ? No, it's just a bigger job. I'll put it on the to-do list. r~
On Wed, 25 Nov 2020 at 04:06, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> As reported in https://bugs.launchpad.net/bugs/1905356
>
> Not implementing SCTLR.A, but all of the other required
> alignment for SCTLR.A=0 in Table A3-1.
Something in this series breaks the 'make check-acceptance'
record-and-replay test:
(30/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
PASS (9.14 s)
(31/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
Timeout reached\nOriginal status: ERROR\n{'name':
'31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
'logdir': '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
(90.19 s)
The log shows the "recording execution" apparently hanging,
with the last output from the guest
[ 3.183662] Registering SWP/SWPB emulation handler
thanks
-- PMM
Cc'ing Pavel
On 12/1/20 4:55 PM, Peter Maydell wrote:
> On Wed, 25 Nov 2020 at 04:06, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> As reported in https://bugs.launchpad.net/bugs/1905356
>>
>> Not implementing SCTLR.A, but all of the other required
>> alignment for SCTLR.A=0 in Table A3-1.
>
> Something in this series breaks the 'make check-acceptance'
> record-and-replay test:
>
> (30/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
> PASS (9.14 s)
> (31/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
> INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
> Timeout reached\nOriginal status: ERROR\n{'name':
> '31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
> 'logdir': '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
> (90.19 s)
>
> The log shows the "recording execution" apparently hanging,
> with the last output from the guest
> [ 3.183662] Registering SWP/SWPB emulation handler
>
> thanks
> -- PMM
>
On 03.12.2020 15:30, Philippe Mathieu-Daudé wrote:
> Cc'ing Pavel
>
> On 12/1/20 4:55 PM, Peter Maydell wrote:
>> On Wed, 25 Nov 2020 at 04:06, Richard Henderson
>> <richard.henderson@linaro.org> wrote:
>>>
>>> As reported in https://bugs.launchpad.net/bugs/1905356
>>>
>>> Not implementing SCTLR.A, but all of the other required
>>> alignment for SCTLR.A=0 in Table A3-1.
>>
>> Something in this series breaks the 'make check-acceptance'
>> record-and-replay test:
>>
>> (30/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
>> PASS (9.14 s)
>> (31/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
>> INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
>> Timeout reached\nOriginal status: ERROR\n{'name':
>> '31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
>> 'logdir': '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
>> (90.19 s)
>>
>> The log shows the "recording execution" apparently hanging,
>> with the last output from the guest
>> [ 3.183662] Registering SWP/SWPB emulation handler
I looked through the patches and it does not seem that they can break
anything.
Could it be the same avocado/chardev socket glitch as in some previous
failures?
What happens when re-running this test?
Pavel Dovgalyuk
On Thu, 3 Dec 2020 at 16:10, Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
>
> On 03.12.2020 15:30, Philippe Mathieu-Daudé wrote:
> > Cc'ing Pavel
> >
> > On 12/1/20 4:55 PM, Peter Maydell wrote:
> >> On Wed, 25 Nov 2020 at 04:06, Richard Henderson
> >> <richard.henderson@linaro.org> wrote:
> >>>
> >>> As reported in https://bugs.launchpad.net/bugs/1905356
> >>>
> >>> Not implementing SCTLR.A, but all of the other required
> >>> alignment for SCTLR.A=0 in Table A3-1.
> >>
> >> Something in this series breaks the 'make check-acceptance'
> >> record-and-replay test:
> >>
> >> (30/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
> >> PASS (9.14 s)
> >> (31/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
> >> INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
> >> Timeout reached\nOriginal status: ERROR\n{'name':
> >> '31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
> >> 'logdir': '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
> >> (90.19 s)
> >>
> >> The log shows the "recording execution" apparently hanging,
> >> with the last output from the guest
> >> [ 3.183662] Registering SWP/SWPB emulation handler
>
> I looked through the patches and it does not seem that they can break
> anything.
> Could it be the same avocado/chardev socket glitch as in some previous
> failures?
> What happens when re-running this test?
I ran it a couple of times with the patchset and it failed the same
way each time. Without is fine.
thanks
-- PMM
On 03.12.2020 19:14, Peter Maydell wrote:
> On Thu, 3 Dec 2020 at 16:10, Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
>>
>> On 03.12.2020 15:30, Philippe Mathieu-Daudé wrote:
>>> Cc'ing Pavel
>>>
>>> On 12/1/20 4:55 PM, Peter Maydell wrote:
>>>> On Wed, 25 Nov 2020 at 04:06, Richard Henderson
>>>> <richard.henderson@linaro.org> wrote:
>>>>>
>>>>> As reported in https://bugs.launchpad.net/bugs/1905356
>>>>>
>>>>> Not implementing SCTLR.A, but all of the other required
>>>>> alignment for SCTLR.A=0 in Table A3-1.
>>>>
>>>> Something in this series breaks the 'make check-acceptance'
>>>> record-and-replay test:
>>>>
>>>> (30/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
>>>> PASS (9.14 s)
>>>> (31/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
>>>> INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
>>>> Timeout reached\nOriginal status: ERROR\n{'name':
>>>> '31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
>>>> 'logdir': '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
>>>> (90.19 s)
>>>>
>>>> The log shows the "recording execution" apparently hanging,
>>>> with the last output from the guest
>>>> [ 3.183662] Registering SWP/SWPB emulation handler
>>
>> I looked through the patches and it does not seem that they can break
>> anything.
>> Could it be the same avocado/chardev socket glitch as in some previous
>> failures?
>> What happens when re-running this test?
>
> I ran it a couple of times with the patchset and it failed the same
> way each time. Without is fine.
I applied the patches and got no failures on my local machine.
Do you have any ideas on debugging this bug?
What does "arm-clang" means? Is the host compiler is clang?
Pavel Dovgalyuk
On Fri, 4 Dec 2020 at 06:17, Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
>
> On 03.12.2020 19:14, Peter Maydell wrote:
> > On Thu, 3 Dec 2020 at 16:10, Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
> >>
> >> On 03.12.2020 15:30, Philippe Mathieu-Daudé wrote:
> >>> Cc'ing Pavel
> >>>
> >>> On 12/1/20 4:55 PM, Peter Maydell wrote:
> >>>> On Wed, 25 Nov 2020 at 04:06, Richard Henderson
> >>>> <richard.henderson@linaro.org> wrote:
> >>>>>
> >>>>> As reported in https://bugs.launchpad.net/bugs/1905356
> >>>>>
> >>>>> Not implementing SCTLR.A, but all of the other required
> >>>>> alignment for SCTLR.A=0 in Table A3-1.
> >>>>
> >>>> Something in this series breaks the 'make check-acceptance'
> >>>> record-and-replay test:
> >>>>
> >>>> (30/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
> >>>> PASS (9.14 s)
> >>>> (31/40) tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
> >>>> INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
> >>>> Timeout reached\nOriginal status: ERROR\n{'name':
> >>>> '31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
> >>>> 'logdir': '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
> >>>> (90.19 s)
> >>>>
> >>>> The log shows the "recording execution" apparently hanging,
> >>>> with the last output from the guest
> >>>> [ 3.183662] Registering SWP/SWPB emulation handler
> >>
> >> I looked through the patches and it does not seem that they can break
> >> anything.
> >> Could it be the same avocado/chardev socket glitch as in some previous
> >> failures?
> >> What happens when re-running this test?
> >
> > I ran it a couple of times with the patchset and it failed the same
> > way each time. Without is fine.
>
> I applied the patches and got no failures on my local machine.
>
> Do you have any ideas on debugging this bug?
> What does "arm-clang" means? Is the host compiler is clang?
Yes, it's a clang build (with the sanitizers enabled, though I didn't
see any output from the sanitizers in the logfile).
thanks
-- PMM
On 12/4/20 12:17 AM, Pavel Dovgalyuk wrote:
> On 03.12.2020 19:14, Peter Maydell wrote:
>> On Thu, 3 Dec 2020 at 16:10, Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> wrote:
>>>
>>> On 03.12.2020 15:30, Philippe Mathieu-Daudé wrote:
>>>> Cc'ing Pavel
>>>>
>>>> On 12/1/20 4:55 PM, Peter Maydell wrote:
>>>>> On Wed, 25 Nov 2020 at 04:06, Richard Henderson
>>>>> <richard.henderson@linaro.org> wrote:
>>>>>>
>>>>>> As reported in https://bugs.launchpad.net/bugs/1905356
>>>>>>
>>>>>> Not implementing SCTLR.A, but all of the other required
>>>>>> alignment for SCTLR.A=0 in Table A3-1.
>>>>>
>>>>> Something in this series breaks the 'make check-acceptance'
>>>>> record-and-replay test:
>>>>>
>>>>> (30/40)
>>>>> tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_aarch64_virt:
>>>>> PASS (9.14 s)
>>>>> (31/40)
>>>>> tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt:
>>>>> INTERRUPTED: Test interrupted by SIGTERM\nRunner error occurred:
>>>>> Timeout reached\nOriginal status: ERROR\n{'name':
>>>>> '31-tests/acceptance/replay_kernel.py:ReplayKernelNormal.test_arm_virt',
>>>>> 'logdir':
>>>>> '/home/petmay01/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/result...
>>>>> (90.19 s)
>>>>>
>>>>> The log shows the "recording execution" apparently hanging,
>>>>> with the last output from the guest
>>>>> [ 3.183662] Registering SWP/SWPB emulation handler
>>>
>>> I looked through the patches and it does not seem that they can break
>>> anything.
>>> Could it be the same avocado/chardev socket glitch as in some previous
>>> failures?
>>> What happens when re-running this test?
>>
>> I ran it a couple of times with the patchset and it failed the same
>> way each time. Without is fine.
>
> I applied the patches and got no failures on my local machine.
>
> Do you have any ideas on debugging this bug?
> What does "arm-clang" means? Is the host compiler is clang?
I have reproduced it:
qemu-system-arm: /home/rth/qemu/qemu/include/tcg/tcg.h:339: get_alignment_bits:
Assertion `(((1 << (10 - 1)) | (1 << (10 - 2)) | (1 << (10 - 3)) | (1 << (10 -
4)) | (1 << (10 - 5)) | (1 << (10 - 6))) & ((1 << a) - 1)) == 0' failed.
Aborted (core dumped)
You need --enable-debug-tcg for this assert.
It's incredibly stupid of avocado to report SIGABRT as a timeout.
r~
© 2016 - 2024 Red Hat, Inc.