the interpreter following the #! has to be an absolute path name.
Not so; relative path works just fine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15429
frame-pointer chains (via EBP), don't continue if EBP doesn't contain
a 4-aligned value. A misaligned EBP is almost certainly invalid --
hence, no loss in unwind capability here -- and the misaligned access
causes gcc 5.1 ubsan alignment checks to fail. So avoid them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15400
Use seg->start instead of a as DebugInfoMapping avma. Normally seg->start
equals a. But when it is not then the size of the map might extend beyond
the segment (and not actually cover the start of the segment). When another
ELF file is them mapped right after this then it triggers an overlap purge
of the DebugInfo. In the case the mapping was for libc or ld.so this then
removes all intercepts causing "bad things".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15398
More recent Xen toolstacks use this for the SID_TO_CONTEXT operation
only, even when XSM is not in use.
XSM is actually an abstraction layer, of which the only current
implementation is FLASK. So this blindly assumes that the backend is
FLASK. Should another XSM backend be invented then we will have to
sort of detecting the correct one.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15384
XENMEM_machphys_compat_mfn_list is functionally identical to
XENMEM_machphys_mfn_list but returns a different list from Xen.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15379
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
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
