so that it is copied into the client space. This avoid warnings from memcheck
because it doesn't think that code inside valgrind is valid.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3591
ifdeffery in a sane way where it's absolutely unavoidable. When
building the core, eg on amd64-linux, the following preprocessor
symbols are defined:
VGA_amd64
VGO_linux
VGP_amd64_linux
etc on other platforms.
Also, include/basic_types.h now defines VG_WORDSIZE and this is what
should be used for ifdefs that need to know the host word size.
ifdefs based on the C compilers built-ins such as __amd64__ etc
are deprecated and will be done away with.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3590
each SegInfo. This reduces by about a factor of 8 the amount of work
needed to find each such record.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3588
for small examples on x86. Still messy, slow, amd64 specifics not
done, and non-null cie.augmentations are not handled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3582
anything. This is needed to get stack snapshots on amd64 code
compiled with -O, and could also be used for stack snapshots on x86
code compiled with -fomit-frame-pointer if it also has CFI info.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3581
Otherwise it doesn't save %ebx across the routine, which is fatal as
%ebx is a callee-save register, it seems.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3578
This fools the redirector to the extent that that strlen et al do not
get reliably intercepted, and hence makes memcheck report some false
errors. Fixing the redirector properly really entails getting rid of
the circularity between the two memory allocators, but that is more
than I have time to sort out right now.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3566
contains what was previously vg_memory.c and also vg_procselfmaps.c,
which is really just a helper for the address space manager.
This just moves code around and modularises it a bit. It doesn't yet
resolve the circular dependencies between ASpaceMgr and various other
chunks of functionality (vg_malloc2, vg_symtab2).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3564
same logging mechanism to emit both end-user messages and debugging-
valgrind-itself messages. This commit creates a new mechanism for the
latter purpose.
The main feature of m_debuglog is that it has zero dependencies on any
other module and therefore can safely operate all the way through
stage1 and stage2 startup. It is restricted to emitting debug info on
file descriptor 2 (stderr), but that's not a big deal.
As a result of this change the basic formatted-print routines
(vprintf) have been moved from vg_mylibc.c into m_debuglog, so that
m_debuglog remains standalone.
The %y format string is currently disabled, since supporting it ("show
symbol corresponding to this address") would create a dependency from
m_debuglog to the entire debug-info reading machinery and all the
stuff that depends on, thereby making a nonsense of m_debuglog being
standalone. Its omission does not seem to cause any regression tests
to fail, though.
The debug logger is activated with "-d". More "-d"s make it more
verbose.
m_debuglog.o is linked into both stage1 and stage2, but as it is
completely standalone this causes no particular problems.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3559
signal frames. This commit looks worse than it is -- really just a
load of moving-code-around.
This is the first multiple-implementation module, in that it has a
single interface (pub_core_sigframe.h) but multiple implementations,
depending on the os-cpu pair. All the grotty details are hidden in
the implementation in m_sigframe/; callers need be aware only of the
interface. Yay.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3556
new[](unsigned long). The 32-bit ones take unsigned int args, not
unsigned longs, and so the existing name-set did not capture them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3549
account for the fact that on amd64 (really, on amd64-linux) the area
up to 128 bytes below the stack pointer is accessible. This meant
moving the definitions of VGA_STACK_REDZONE_SIZE to tool-visible
places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3546
because the redirect syms are set up only after the initial read of
/proc/self/maps and by then ld-linux.so.2 is already aboard. Fixing
this properly requires fixing the address space management stuff
properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3534
core.h and tool.h into pub_core_errormgr.h and pub_tool_errormgr.h. All
just to improve general modularity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3532
string explaining more detail if the assertion fails (eg. the value of the
bogus variable) using printf-style format arguments.
One consequence of this is that you can do something like
vg_assert2(0, "bad bad bad");
instead of calling VG_(core_panic). The advantage of the new approach is
that it shows the file/function/line info for the failing code, whereas
VG_(core_panic)() does not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3528
controlled (rounding user malloc requests up to a multiple of 4).
Subsequent changes to memcheck made it more or less pointless, it is a
time waster in the malloc/free path, and nobody ever used it AFAIK.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3522
make their role clearer and their behaviour more consistent with the fields
describing the client's stack. Also made the code in x86-linux/syscalls.c
and amd64-linux/syscalls.c more word-size-independent, which is not strictly
necessary but makes the code similarities between the two files more
obvious.
One consequence of this is that Valgrind's stack on AMD64 is now 16384 * 8
bytes, rather than 16384 * 4 bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3520
