https://bugs.kde.org/show_bug.cgi?id=322935
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #40 from Paul
https://bugs.kde.org/show_bug.cgi?id=322935
Sam James changed:
What|Removed |Added
CC||s...@gentoo.org
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #39 from Graham Leggett ---
For the record, moving /etc/ld.so.preload out of the way and in the process
disabling the RPI's memcpy optimisations causes valgrind to run correctly on
the RPi.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=322935
Graham Leggett changed:
What|Removed |Added
CC||minf...@sharp.fm
---
https://bugs.kde.org/show_bug.cgi?id=322935
WernerF changed:
What|Removed |Added
CC||werner.fr...@web.de
--- Comment
https://bugs.kde.org/show_bug.cgi?id=322935
Tom Hughes changed:
What|Removed |Added
CC||alexander.ress...@gmail.com
---
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #35 from Jeffrey Walton ---
(In reply to Julian Seward from comment #27)
> This keeps cropping up, for example most recently in bug 366464. Maybe
> I should explain more why this isn't supported
>
> Truth be told, I
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #34 from Mark Wielaard ---
(In reply to Peter Maydell from comment #33)
> (In reply to Mark Wielaard from comment #32)
> > valgrind should already intercept the memcmp from glibc. This one however is
> > in a different
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
https://bugs.kde.org/show_bug.cgi?id=322935
Mark Wielaard changed:
What|Removed |Added
CC||m...@redhat.com
--- Comment
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
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
https://bugs.kde.org/show_bug.cgi?id=322935
Julian Seward changed:
What|Removed |Added
CC||noloa...@gmail.com
---
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #27 from Julian Seward ---
This keeps cropping up, for example most recently in bug 366464. Maybe
I should explain more why this isn't supported. It's because we don't have
a feasible way to do it. Valgrind's JIT
14 matches
Mail list logo