https://bugs.kde.org/show_bug.cgi?id=377463
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #1 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
Quick feedback:
More generally, all valgrind client requests arguments
for client requests in valgrind.h or memcheck.h could potentially
be uninitialised, and so should be checked.
Client requests are implemented by macros that expand to a very
'strange' sequence of instructions, recognised by the JIT so as to switch
from the simulated CPU to the real CPU (and execute the client request
on the real CPU).
To trigger an error, it means that the macros would need to add some
fake jump instruction to be evaluated on the simulated CPU to trigger
an error msg.
In other words, all the args of the macros should first be checked
by expanding the code with e.g. the macro
#define TRIGGER_MEMCHECK_ERROR_IF_UNDEFINED(x) \
if ((ULong)x == 0) __asm__ __volatile__( "" ::: "memory" )
similarly to what is done in
coregrind/m_replacemalloc/vg_replace_malloc.c
for malloc arguments.
However, vg_replace_malloc.c is "pure valgrind code", only loaded when
running under Valgrind, while client request expanded code is part of
the compiled application code, even when not running under Valgrind.
So, fixing this bug will increase the size and/or cost of the client
request expanded code, even when not running under valgrind.
Wondering if this additional size/cost is ok.
For sure, this needs further discussion, once a prototype patch is done.
--
You are receiving this mail because:
You are watching all bug changes.
