counterpart VG_(client_alloc) to VG_(get_memory_from_mmap_for_client).
Man, this low level memory management is an undisciplined mess.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3376
itself. Doing so -- in this case for libc.so.6 -- confuses the
redirection machinery and so messes up redirections to
mac_replace_strmem.c, which in turn causes memcheck to report
spurious errors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3356
because the added VG_(find_root_memory)() is just a stub. And there's a
problem with overlap checking that I haven't worked out yet. Still it's a
start. The commit also brings Memcheck back into the build process,
although mc_main.c is entirely commented out at the moment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3352
overhaul of the thread support. Many things are now probably broken,
but at least with --tool=none, simple and not-so-simple threaded and
non-thread programs work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3265
* remove initialisation-time circularities by not using the
skiplist mechanism and therefore not using any dynamically
allocated memory in support of this mechanism
* Add comments about how it works (it is pretty opaque) so as
to help future maintainers/bug-fixers
It only just works and many things are still broken. That should
improve rapidly however.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3242
table/cache management. Two main changes. (1) Translation areas are
recorded using VexGuestExtents, so that Vex is now properly supported
and code deletion works correctly. (2) Low overhead BB profiling,
enabled by the --profile-flags=<XXXXXXXX> option. This finds the top
N bbs at exit and shows them, so as to give a basis from which to do
performane tuning.
To support this, the way tt/tc work is changed. It is still a
sectored arrangement, but now each sector has its own hash table.
This simplifies a lot of things.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3226
string in valgrind.pc.in, so that they describe Valgrind as a "dynamic
binary instrumentation framework", and don't mention platforms at all.
I had to tweak the regtest filters a bit for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3178
Int VG_(do_syscall) ( UInt, UWord, UWord, UWord, UWord, UWord, UWord );
to replace the previous:
Int VG_(do_syscall) ( UInt, ... )
Reason being that sometimes you could get incorrect args passed, when
passing 32-bit ints on 64-bit platforms. I also added macros
VG_(do_syscall[123456]) to make life easier, and converted all the
relevant calls.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3143
state pointer points directly at the ThreadState.arch.vex field, thus
updating it in place and avoiding a lot of code (and time-wasting)
which copies stuff back and forth to baseBlock.
Fix zillions of other places in the system where the current thread id
is needed. It is now passed to all needed places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3090
- Added include/x86-linux/ and include/linux/ subdirectories, with Makefile.am
files.
- Overhauled the definitions of kernel types. include/vg_kerneliface.h is now
three files, include/linux/vki.h, include/x86-linux/vki_arch.h, and
include/x86-linux/vki_arch_posixtypes.h. These files separate the
common/Linux and x86/Linux parts cleanly. All code is copied verbatim from
the relevant kernel headers, except that VKI_/vki_ prefixes are added as
necessary to distinguish them from glibc types. (This is done consistently,
unlike previously when some types did not have the prefixes.)
All code is clearly marked to show which particular header file it came from,
and the Linux version used. (I used 2.6.8.1, the most recent stable release,
for all of them.)
A few of the types changed; this is because they changed between the older
versions of Linux and the current 2.6.8.1. I checked that all these changes
were ok with respect to backwards compatibility for our purposes.
- vg_unsafe.h has been removed; we are no longer including any kernel headers,
as we have our own copies for everything. This is because installed kernel
headers are not reliable, and often cause compilation problems. (bug
#92420 is a recent example)
- Removed some no-longer-needed header-presence tests from configure.in.
- Some code in the rest of Valgrind was changed to account for some slight
changes in the names of our VKI_/vki_ kernel constants and types.
- Updated README_MISSING_SYSCALL_OR_IOCTL accordingly.
- Fixed off-by-one error with VKI_GDT_ENTRY_TLS_MAX (merged from stable branch)
The end result is that the kernel types situation should be much clearer, and
similar files can be created relatively easily for other architectures as
necessary.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2884
changed to name the last byte in Valgrind's section, rather than one past the
last byte. This was because the last byte is 0xffffffff, and so one past gave
0x0, which screwed things up.
However, when this change was made, all the places where VG_(valgrind_end) is
used weren't adjusted appropriately. So this commit makes those adjustments.
It also renames the variable as VG_(valgrind_last), which makes the difference
between it and the other VG_(*_end) variables much clearer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2672
__attribute((regparm(n))) with REGPARM(n) everywhere. REGPARM() is defined in
vg_skin.h, but will eventually be defined separately for each arch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2601
lower than that of any existing segment, it got it wrong due to the confusing
SkipList API. I wonder how many more bugs like that there are...?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2596
requires padding of the address space around calls to io_setup in order
to constrain the kernel's choice of address for the I/O context.
Based on patch from Scott Smith <scott-kde@gelatinous.com> with various
enhancements, this fixes bug #83060.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2485
1. It simplifies various things a bit.
2. Valgrind/tools will run out of memory later than currently in many
circumstances. This is good news esp. for Calltree.
Some things were going in V's 128MB heap, and some were going in V's 128MB map
segment. Now all these things are going into a single 256MB map segment.
stage2 has been moved down to 0xb0000000, the start of the 256MB map segment.
The .so files needed by it are placed at 0xb1000000 (that's the map_base).
This required some bootstrapping at startup for memory -- we need to allocate
memory to create the segments skip-list which lets us allocate memory...
solution was to make the first superblock allocated a special static one.
That's pretty simple and enough to get things going.
Removed vg_glibc.c which wasn't doing anything anyway.
Removed VG_(brk) and associated stuff, made all the things that were calling it
call VG_(mmap)() instead.
Removed VG_(valgrind_mmap_end) which was no longer needed.
Rejigged the startup order a bit as necessary.
Moved an important comment from ume.c to vg_main.c where it should be.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2482
