two halves: stacktrace.c, which deals with getting, traversing and printing
stack traces; and execontext.c, which deals with storing stack traces
permanently in a way that avoids duplicates, and comparing them.
One nice outcome: previously we were often creating ExeContexts, which live
forever, even when they were only needed temporarily. Ie. this was a memory
leak, which has been removed.
As part of this, new headers have been created, carved off core.h and
tool.h. Lots of function names have changed, too.
In Massif, I also changed a lot of "eip" names to "ip" to make them less
x86-specific.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3429
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
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
It compiles, but aborts immediately if you try to run it.
I didn't include ldt.c; I'm not sure how the LDT is used on AMD64. It can be
added later if necessary.
While doing this, did some 64-bit cleanness fixes:
- Added necessary intermediate casts to ULong to avoid warnings when converting
ThreadId to void* and vice versa, in vg_scheduler.c.
- Fixed VALGRIND_NON_SIMD_CALL[0123] to use 'long' as the return type.
- Fixed VALGRIND_PRINTF{,BACKTRACE} to use unsigned longs instead of unsigned
ints, as needed.
- Converted some offsets in vg_symtab2.h from "Int" to "OffT".
- Made strlen, strncat, etc, use SizeT instead of 'unsigned int' for the length
parameter.
- Couple of other minor things.
I had to insert some "#ifdef __amd64__" and "#ifndef __amd64__" guards in
places. In particular, in vg_mylibc.c, some of our syscall wrappers aren't
appropriate for AMD64 because the syscall numbering is a bit different in
places. This difference will have to be abstracted out somehow.
Also rewrote the sys_fcntl and sys_fcntl64 wrappers, as required for AMD64.
Also moved the ipc wrapper into x86, since it's not applicable for
AMD64. However, it is applicable (I think) for ARM, so it would be nice
to work out a way to share syscall wrappers between some, but not all,
archs. Hmm. Also now using the real IPC constants rather than magic
numbers in the wrapper.
Other non-AMD64-related fixes:
- ARM: fixed syscall table by accounting for the fact that syscall
numbers don't start at 0, but rather at 0x900000.
- Converted a few places to use ThreadId instead of 'int' or 'Int' for
thread IDs.
- Added both AMD64 and ARM (which I'd forgotten) entries to valgrind.spec.in.
- Tweaked comments in various places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3136
- 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
safer kernel interface to signalling a particular thread and it ensures
you can only send a signal to one of your own threads.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2795
been changed to return the ID of the thread group leader but which do not
have a gettid system call.
This breaks VG_(gettid) which assumes that the getpid system call will
give the thread ID if the gettid system call does not exist.
The (horrible) solution is to use readlink to see where /proc/self points
when the gettid system call fails.
BUG: 82114
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2771
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
- removed various things that are no longer used
- made (module-)local some things that were global
- improved the formatting in places
Removed about 160 lines of code, and non-trivially reduced the number
of global entities.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2541
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
add a segment mapping to the segment skip-list, and then often the caller of
VG_(mmap) would do another one for the same segment, just to change the SF_*
flags. Now VG_(mmap) gets passed the appropriate SF_* flags so it can do it
directly. This results in shorter, simpler code, and less work at runtime.
Also, strengthened checking in VG_(mmap), POST(mmap), POST(mmap2) -- now if the
result is not in the right place, it aborts rather than unmapping and
continuing. This is because if it's not in the right place, something has
gone badly wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2466
