https://codereview.chromium.org/26006004/diff/33001/src/deoptimizer.cc
File src/deoptimizer.cc (right):
https://codereview.chromium.org/26006004/diff/33001/src/deoptimizer.cc#newcode114
src/deoptimizer.cc:114: Deoptimizer* deoptimizer = new
Deoptimizer(isolate,
On 2013/10/10 14:18:07, danno wrote:
This big unpoison of the stack is total overkill. The deoptimizer
copies a
specific number of frames from the stack to the input_ of buffer of
the
Deoptimizer. This is done after returning from this routine in the
hand-written
assembly code of the deoptimizer. After that, the
Deoptimizer::ComputeOutputFrames method inspect this buffer to build
the output
frames. You should be able to precisely unpoison just the input buffer
for which
you have the exact size at the beginning of
Deoptimizer::ComputeOutputFrames.
Thanks, this is very helpful!
https://codereview.chromium.org/26006004/diff/33001/src/msan.h
File src/msan.h (right):
https://codereview.chromium.org/26006004/diff/33001/src/msan.h#newcode52
src/msan.h:52: __msan_unpoison(&(c), sizeof(c)); \
On 2013/10/10 14:18:07, danno wrote:
Why are these not covered by the 64K above? From the usage, it appears
the
arguments are always parameters to the function this macro is embedded
in. If
they are pushed before the call, then they lie at an address above
locals in the
current frame?, so the &dummy call should cover them.
Uninit information for function arguments is passed though a special TLS
slot, unpoisoning stack won't affect it. This is an unfortunate
limitation of operating at LLVM IR level - we don't know the details of
the function calling convention and have to work with an abstact
argument list.
https://codereview.chromium.org/26006004/diff/33001/src/platform-posix.cc
File src/platform-posix.cc (right):
https://codereview.chromium.org/26006004/diff/33001/src/platform-posix.cc#newcode71
src/platform-posix.cc:71: #include "msan.h"
On 2013/10/10 14:18:07, danno wrote:
Here and elsewhere: None of these includes should be hard wired (they
should be
conditionally included based on whether MEMORY_SANITIZER is active).
But msan.h is in fact the place where things like MSAN_RUNTIME_FUNCTION
are defined in different ways depending on MEMORY_SANITIZER. If we
include it conditionally, then all uses of those annotations would also
need to be surrounded by #ifdef MEMORY_SANITIZER.
https://codereview.chromium.org/26006004/diff/33001/src/platform-posix.cc#newcode211
src/platform-posix.cc:211: #if defined(ADDRESS_SANITIZER) ||
defined(MEMORY_SANITIZER) || \
On 2013/10/10 14:18:07, danno wrote:
This change been landed separately, why is this in this CL?
That was in a different repository, I think.
https://codereview.chromium.org/26006004/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
