The XEN_DOMCTL_[gs]et_vcpu_msrs work simiarly to the other get/set pairs,
taking a vcpu, buffer and size. A query with a buffer of NULL is a request
for the maximum size.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15370
The VKI_XEN_DOMCTL_[gs]et_ext_vcpucontext hypercalls have had interface
changes, but are largly just extentions of the existing structure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15369
XEN_DOMCTL_setvcpuextstate reads a vcpu, size and buffer pointer, and reads
size bytes from the buffer. It has no outputs.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15368
Xen only writes into the provided buffer if the guest handle was not NULL.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15367
The change causing the sysctl bump is not in an implemented subop yet, so no
change is required. The change causing the domctl bump is in an implemented
subop, but has also been reverted in favor of a different way of performing
the same actions. Therefore, there is no net difference.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15365
If the compiler supports -fno-sanitize=alignment use it.
Otherwise, there will be complaints about misaligned
memory accesses. This is needed for GCC 5.1.
If that flag is not supported simply pass in -fsantize=undefined
and assume that it won't check for alignment violations (which
is true for GCC 4.9).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15351
gdb 7.9 reports new threads at different moment than the previous versions.
Filter these new threads lines so as to not be dependent on this
gdb aspect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15347
324181 was previously closed with a solution to always make
MAP_32BIT fail. This is technically correct/according to the doc,
but is not very usable.
This patch ensures that MAP_32BIT mmap is succesful, as long as
aspacemgr gives a range in the first 2GB
(so, compared to a native run, MAP_32BIT will fail much more quickly
as aspacemgr does not reserve the address space below 2GB on a 64 bits).
Far to be perfect, but this is better than nothing.
Added a regression test that test succesful mmap 32 bits till
the 2GB limit is reached.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15341
A little style improvement for load_indexed_instructions test including
addition of new instruction to be tested - lhx (supported as of VEX r3152).
Related issue - BZ #345987.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15340
whether -Wformat-security is supported. Special handling is needed.
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 accepts -Wformat-security
without -Wformat being present on the command line. Other GCC
versions will issue a warning if -Wformat is missing. r15323
adds -Werror to AC_GCC_WARNING_SUBST and therefore turns that
warning into an error. With the consequence that
-Wformat-security appears to be unsupported -- a false conclusion.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15331
in case an unrecognised command line option is encountered. configure.ac
however was assuming just that which led to compile time warnings later on.
Add -Werror to the configure bits to make clang behave like gcc in this
regard. Fixes BZ #348565.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15323
MC_(helperc_LOADV32le), MC_(helperc_LOADV16le) and
MC_(helperc_LOADV8). This improves performance by around 5% to 7% in
the best case, for run-of-the-mill integer code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15317
