https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #11 from Julian Seward <jsew...@acm.org> ---
(In reply to Carl Love from comment #10)
> Created attachment 138846 [details]
> PPC add copy, paste, cpabort support
>
> Updated patch to add the Memcheck trickery to get Memcheck to detect
> undefined bits in the copy paste buffer.
I *think* this is OK now, with two caveats:
+UInt copy_paste_abort_dirty_helper(UInt addr, UInt op) {
This will not build on anything except a Power target. It needs to be
ifdef'd in the usual way.
Ok to land if you fix the above plus sanity check the following issue.
Here's another clarifying comment; I think you should add something
like this. It's about the "paste" effects annotations. If I understand
the code correctly, for "paste" you will now have annotations
Ifx_Write at (wherever the target address is) for 128 bytes
and also
the function takes two args `EA_base` and `operation`
and it returns the uint32_t that you mention.
How Memcheck will instrument that is, if there is any undefinedness in
the inputs, then all of the outputs will be undefined. Hence
if EA_base or operation contain any undefined bits
then the return value is undefined and the specified 128-byte memory area
are undefined after the call
else the return value is undefined and the specified 128-byte memory area
are defined after the call
The point is .. if I understand "paste" correctly, the destination address is
not part of the "normal" program address space. So the Ifx_Write annotation
in this case is irrelevant. Indeed, if the destination address is part of
*some other* address space, then we actually need to omit that Ifx_Write
annotation, because othewise Memcheck will update its status bits for that
address range in this program's address space, which would be wrong.
So .. I hope that makes sense.
--
You are receiving this mail because:
You are watching all bug changes.
