(1) It is always invalid for the incoming segment pointer to be
out of range. Assert that.
(2) Let the compiler do the address arithmetic. They're good at that
and therefore:
(3) No asserts needed to check the result.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14933
trash list. Not doing so was causing r12 to get corrupted by the
called function, which lead to some very strange failures in Helgrind
on arm32. Fixes#344033.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14929
confusing SP and LR and resulting in no backtraces during internal
assertion failures etc on this platform. Fixes#343219. Noticed by
dimitry@google.com.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14928
in the inline assembly, because gcc doesn't like that when compiling
for Thumb. And this file is compiled for Thumb during "make check".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14927
ppc64 might fall back to socketcall in some cases, but arm64 always uses
accept4 syscall directly. Some (confusing) background on when/how glibc
(wrongly) decides to use a direct accept4 or the socketcall system call:
https://sourceware.org/ml/libc-alpha/2013-12/msg00014.html
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14926
rather than using a compile time constant.
This is in preparation for a future change by Florian, to have
the max nr of threads specifiable at startup via a clo
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14924
The list of segnames was shown with a seq nr,
while each segment was referencing its segname with an offset.
The patch ensures that at all places, both the seq nr and the
offset is output
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14911
made from file-backed mappings (AOT code, basically) that is different
from the default behaviour as specified by --vex-iropt-register-updates.
New flag is --px-file-backed=, with the same possible args as
--vex-iropt-register-updates has.
Add a new flag --px-default, which is a short alias for
--vex-iropt-register-updates.
Add one line of stats output when --stats=yes, showing counts of how
many translations have been made under each of the 4 different PX
optimisation settings.
No user-visible change if you don't use the new flags.
Relies on VEX API change in r3084.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14906
empty then-body after the condition rather than merely ";", which is
confusing and is inconsistent with the rest of the arg handling code.
No functional change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14904
The validity of this change follows from the following observations:
(1) There is a single source for allocating and storing segment names,
namely allocate_segname.
(2) For all invocations of allocate_segname the returned value (which
represents the segmant name) is assigned to NSegment::fnIdx.
(3) All but one assignments to NSegment::fnIdx assign allocate_segname.
The single exception assigns -1 in init_nsegment. That function is
called whenever a new segment (named or unnamed) is allocated.
For a segment name to become unused there must be an assignment to
NSegment::fnIdx which was previously assigned a return value from
allocate_segname. There is no such assignment.
It follows that all segment names are in use at all times, hence
SegName::inUse == True for all SegNames. So we can constant fold it
and don't need to represent it.
Pass 3 in preen_nsegments is obsolete as there are no segment names to
garbage collect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14898
address space manager. Callers should neither modify the string nor
free it (as the string resides is statically allocated memory). That
calls for a const HChar *
The type change exposed two bugs. One in m_addrinfo.c and one in
m_debuginfo.c. In both cases the returned string could possibly be freed later
on. So we need to strdup it first. Now fixed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14886
