https://bugs.kde.org/show_bug.cgi?id=392146
--- Comment #17 from Peter Maydell ---
The Linux kernel documents which ID registers and which fields in those
registers it exposes here:
https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt . Does
FreeBSD expose the same set, or a
https://bugs.kde.org/show_bug.cgi?id=432387
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #7 from
https://bugs.kde.org/show_bug.cgi?id=414268
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #4 from
https://bugs.kde.org/show_bug.cgi?id=414268
--- Comment #7 from Peter Maydell ---
Your logic attempting to identify v8.1, v8.2, etc isn't right. For instance:
+ /* Must be at least v8.2 if DC CVAP instruction available. */
+ if (have_dpbcvap)
+SET_VEX_ARM64_ARCHLEVEL(vai.h
https://bugs.kde.org/show_bug.cgi?id=414268
--- Comment #15 from Peter Maydell ---
The closest thing to single-source-of-truth is the architectural ID registers,
which these days a Linux kernel will make available to userspace via
trap-and-emulate and which presumably Valgrind does or should
https://bugs.kde.org/show_bug.cgi?id=369509
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #8 from
https://bugs.kde.org/show_bug.cgi?id=395777
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #2 from
https://bugs.kde.org/show_bug.cgi?id=396001
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #1 from
https://bugs.kde.org/show_bug.cgi?id=392146
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #3 from
https://bugs.kde.org/show_bug.cgi?id=393036
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #1 from
https://bugs.kde.org/show_bug.cgi?id=376279
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #5 from
https://bugs.kde.org/show_bug.cgi?id=386425
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #5 from
https://bugs.kde.org/show_bug.cgi?id=386425
--- Comment #9 from Peter Maydell ---
Yes, I just mean that each thread sees its own copy with the value it last
wrote. On exec() a fresh process image starts out with a zero value. On fork()
or clone() a new thread or process inherits the value from
https://bugs.kde.org/show_bug.cgi?id=381556
--- Comment #5 from Peter Maydell ---
That workaround change looks wrong to me. Surely Valgrind supports at least FP
and Neon ?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=381556
--- Comment #6 from Peter Maydell ---
Looking back in the history, my comment #3 should have enough information for
somebody who knows what instructions Valgrind implements to be able to set the
hwcaps appropriately.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=381556
--- Comment #11 from Peter Maydell ---
The A-profile Arm ARM can be downloaded from
https://developer.arm.com/products/architecture/a-profile/docs without
requiring a login/clickthrough/etc.
--
You are receiving this mail because:
You are watching
https://bugs.kde.org/show_bug.cgi?id=381556
--- Comment #12 from Peter Maydell ---
Sorry about the bogus kernel-source link -- I made the mistake of linking to
the 'latest' version, which of course is a moving target so the line number
reference gets out of date. Here's the lin
https://bugs.kde.org/show_bug.cgi?id=381556
--- Comment #13 from Peter Maydell ---
Based on a quick grep of guest_arm64_toIR.c to see what insns it has, I think
Valgrind should be setting the hwcap bits AES, PMULL, SHA1, SHA2, CRC32, FP,
ASIMD and making the rest zero.
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=377420
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #1 from
https://bugs.kde.org/show_bug.cgi?id=377420
--- Comment #2 from Peter Maydell ---
Doh, I meant bug 344802...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=377966
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #2 from
https://bugs.kde.org/show_bug.cgi?id=377966
--- Comment #4 from Peter Maydell ---
Good point -- there's no inherent reason why valgrind would need to use the
same cache line size that the host is using for DC ZVA. You can just pick an
arbitrary value as long as you're consistent with
https://bugs.kde.org/show_bug.cgi?id=381556
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #3 from
https://bugs.kde.org/show_bug.cgi?id=366345
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #1 from
https://bugs.kde.org/show_bug.cgi?id=366464
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #2 from
https://bugs.kde.org/show_bug.cgi?id=366464
--- Comment #4 from Peter Maydell ---
(In reply to Jeffrey Walton from comment #3)
> Is there a way to get Valgrind's portion of the bug tracker to return search
> results that are no longer open? Or at least include the ones marked as
&
https://bugs.kde.org/show_bug.cgi?id=369459
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #2 from
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #8 from Peter Maydell ---
FWIW QEMU is switching to emulating atomics (including ll/sc) via a common
"cmpxchg" IR operation (which is then implemented in the backend via an ll/sc
loop or whatever the host CPU has). This resu
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #14 from Peter Maydell ---
I think the assertion about "real world code not caring" is based on some
popular CPUs not having an ll/sc combination (like x86!), and so portable
atomicity primitives can't assume you don't
https://bugs.kde.org/show_bug.cgi?id=361726
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #4 from
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #29 from Peter Maydell ---
The way QEMU's JIT handles this kind of thing is that we track each translated
code block by (start PC, cpu state flags), where the flags track the subset of
the CPU's current state that we've
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #31 from Peter Maydell ---
If your JIT architecture doesn't permit a QEMU-style approach I would be
tempted to go with "implement SETEND to throw away JITted code and print a
warning about poor performance". At the moment p
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #33 from Peter Maydell ---
(In reply to Mark Wielaard from comment #32)
> valgrind should already intercept the memcmp from glibc. This one however is
> in a different library libcofi_rpi.so which looks like some kind of hack to
>
https://bugs.kde.org/show_bug.cgi?id=362934
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #3 from
https://bugs.kde.org/show_bug.cgi?id=360425
Peter Maydell changed:
What|Removed |Added
CC||peter.mayd...@linaro.org
--- Comment #3 from
35 matches
Mail list logo
