the m_syscalls module. Fundamentally the aim of the overhaul is to
clean up the logic and abstractions surrounding syscalls in order that
we can cleanly support ppc32 and other new targets. Aims in detail:
* To further decouple the syscall PRE/POST wrappers from specifics of
how those values are stored on a given platform. The wrappers look
the same as they did before, mostly (eg, references to ARGn and
RES are unchanged), but now those macros refer to values in structs
SyscallArgs and SyscallStatus (see priv_types_n_macros.h).
* Complete overhaul of the driver logic for syscalls. The resulting
logic is algorithmically identical to what we had before, but is
more documented, and deals with moving arg/result data between
platform specific representations and the canonical forms in
structs SyscallArgs and SyscallStatus.
* Also as a result of this change, remove problems in the old logic
due to assignments of RES in PRE wrappers trashing the ARGs whilst
we still need to see them.
* Lots of other cleanups and documentation. There is extensive
commentary in syscalls-main.c.
The driver logic has been placed in its own file, syscalls-main.c.
New/deleted files in m_syscalls:
* syscalls.c is divided up into syscalls-main.c, containing driver
logic, and syscalls-generic.c, containing generic Unix wrappers.
* priv_syscalls.h is chopped up into priv_types_n_macros.h
and priv_syscalls-{generic,main}.h.
------------
All the above changes are in m_syscalls. However there is one
system-wide change as a result of all this.
The x86-linux assumption that syscall return values in the range -4095
.. -1 are errors and all others are values, has been done away with
everywhere. Instead there is a new basic type SysRes which holds a
system call result in a platform-neutral way.
Everywhere that previously an Int would have held a system call
result, there is now a SysRes in its place.
------------
Almost everything works on SuSE 9.1 (LinuxThreads) again. NPTL will
still be majorly broken; I will commit fixes shortly. AMD64 is also
totalled. I will get to that too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3849
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
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
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
This required some tricks with casting to maintain Memcheck's silly (ie.
negative) arg checking. The allocator was also changed accordingly. It
should now be able to allocate more than 4GB blocks on 64-bit platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2906
