Public bug reported:
arm optimized-routines have sve string functions with test code.
the test worked up until recently: with qemu-5.2.0 i see
$ qemu-aarch64 build/bin/test/strnlen
PASS strnlen
PASS __strnlen_aarch64
__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32
input: "ab
The 06/05/2020 13:26, Richard Henderson wrote:
> That assert is just wrong -- it's attempting to sanity check a virtual address
> against a property associated with the physical address, and even doing that
> incorrectly.
>
> I've pushed a fixup to the branch to remove it, and I'll look into addin
The 06/03/2020 09:21, Richard Henderson wrote:
> On 6/3/20 6:50 AM, Szabolcs Nagy wrote:
> > thanks my tests now get further but later i run into
> > the previous assert failure:
> >
> > target/arm/mte_helper.c:97:allocation_tag_mem: assertion failed: (tag_size
>
The 06/02/2020 14:58, Richard Henderson wrote:
> On 5/29/20 5:04 AM, Szabolcs Nagy wrote:
> > again i'm using the branch at
> >
> > https://github.com/rth7680/qemu/tree/tgt-arm-mte
> >
> > to test armv8.5-a mte, now qemu-system-aarch64 segfaults
> > an
again i'm using the branch at
https://github.com/rth7680/qemu/tree/tgt-arm-mte
to test armv8.5-a mte, now qemu-system-aarch64 segfaults
and it's easy to reproduce: minimal source and static
linked binary is attached (should be executed on linux
with mte support, i used mte-v4 kernel with reverted
The 05/07/2020 10:21, Richard Henderson wrote:
> A reproducer would be most helpful.
>
> Something that can help is saving a VM snapshot with the kernel booted and the
> user logged in, just ready to run the test program. Then you can get back to
> exactly the state you want before things go wron
The 05/06/2020 13:57, Szabolcs Nagy wrote:
> However later on during testing malloc with PROT_MTE
> i got a qemu assert failure:
>
> Bail out! ERROR:/S/target/arm/mte_helper.c:97:allocation_tag_mem: assertion
> failed: (tag_size <= in_page)
>
> i can reproduce it, but i
The 04/24/2020 12:47, Richard Henderson wrote:
> On 4/21/20 9:39 PM, Richard Henderson wrote:
> > Yep. I failed to update aarch64_pstate_valid_mask for TCO.
> > Will fix. Thanks,
>
> Fixed on the branch.
>
> I still need to work out how best to plumb the arm,armv8.5-memtag property so
> the dev
i'm using the branch at
https://github.com/rth7680/qemu/tree/tgt-arm-mte
to test armv8.5-a mte and hope this is ok to report bugs here.
i'm doing tests in qemu-system-aarch64 with linux userspace
code and it seems TCO bit gets cleared after syscalls or other
kernel entry, but PSTATE is expected
note that the bug affects qemu-user on a glibc system too in case
malloc is interposed: glibc can only take the internal locks of
its own malloc implementation, any other malloc has the same issue
as musl's after fork.
--
You received this bug notification because you are a member of qemu-
devel-
Public bug reported:
static pie binaries may not get a reasonable brk,
with glibc this means they crash in early tls setup code:
https://sourceware.org/bugzilla/show_bug.cgi?id=24152
qemu seems to put brk at the end of the data segment,
but if the stack starts (ends) right next to it then
allocat
** Also affects: qemu
Importance: Undecided
Status: New
** No longer affects: qemu (Ubuntu)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1813398
Title:
qemu user calls malloc after fork
12 matches
Mail list logo
