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
platforms, otherwise the address-masking operations to establish
alignment and primary-mappability are wrong on 64-bit platforms.
Also set the size of fast-mapped address space on 64-bit platforms to
16G.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3580
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
vex rev 1144.
* Observe that mkLazy2 generates IR which often turns into
long and slow code sequences in the back end, primarily because
PCast operations are expensive. Add a couple of special
cases which give noticably better performance when handling
FP-intensive code on x86.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3572
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
