https://bugs.kde.org/show_bug.cgi?id=322935
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #40 from Paul Floyd
https://bugs.kde.org/show_bug.cgi?id=322935
Sam James changed:
What|Removed |Added
CC||s...@gentoo.org
--
You are receiving this mail bec
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 because:
You are w
https://bugs.kde.org/show_bug.cgi?id=322935
Graham Leggett changed:
What|Removed |Added
CC||minf...@sharp.fm
--- Comment #38 from Graham L
https://bugs.kde.org/show_bug.cgi?id=322935
WernerF changed:
What|Removed |Added
CC||werner.fr...@web.de
--- Comment #37 from WernerF ---
https://bugs.kde.org/show_bug.cgi?id=322935
Tom Hughes changed:
What|Removed |Added
CC||alexander.ress...@gmail.com
--- Comment #36 from T
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 don't believe this 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 library libcofi_rpi.so
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
> interpose
https://bugs.kde.org/show_bug.cgi?id=322935
Mark Wielaard changed:
What|Removed |Added
CC||m...@redhat.com
--- Comment #32 from Mark Wiela
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 people trying to va
https://bugs.kde.org/show_bug.cgi?id=322935
--- Comment #30 from Julian Seward ---
(In reply to Peter Maydell from comment #29)
> The way QEMU's JIT handles this kind of thing [..]
Thanks for the explanation. I was indeed wondering how QEMU handled this.
Yes .. if I could redo the basic JIT ar
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 baked into the transl
https://bugs.kde.org/show_bug.cgi?id=322935
Julian Seward changed:
What|Removed |Added
CC||noloa...@gmail.com
--- Comment #28 from Julian
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 instruments code blocks a
15 matches
Mail list logo