rather than giving the warning about the syscall being missing. (Nb: this only
applies to syscall numbers for which the kernel has no corresponding syscall;
Valgrind will still give that warning if new syscalls are added to the kernel.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2962
- All memory-related errors are now clear whether they are caused by
unaddressable or uninitialised memory. (Previously, writes were
clearly addressability errors, but reads could be either.) Mostly
done by replacing the 'isWrite' field in MAC_Error with 'isUnaddr'.
Also, mc_check_readable() now indicates not just if an error occurred,
but what kind of error (ie. addressability or definedness).
- Put machinery into place in the core to inform tools when registers
are being read by the core -- ie. a 'pre_reg_read' event. Most
notably, this facilitates syscall scalar arg definedness checking for
Memcheck. Currently this is only working for read(), write(), exit()
and exit_group(), but it will be extended as the syscalls are
overhauled as part of the arch-abstraction work.
A consequence of this is that the ParamErr messages have changed. This:
Syscall param write(buf) contains uninitialised byte(s)
now means that the pointer 'buf' is partially undefined. If the memory
pointed to by 'buf' is partially undefined or unaddressable, it says one of:
Syscall param write(buf) points to uninitialised byte(s)
Syscall param write(buf) points to unaddressable byte(s)
The docs have been updated accordingly.
I also added a couple of regression tests.
These two change sare notable for being the first improvements to
Memcheck's checking/errors in a long time.
I also folded mc_clientreqs.c into mc_main.c, which saves exporting a
whole bunch of things that are not used anywhere else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2949
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
- 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
neater. Also remove some dodgy CFLAGS+= lines.
I had to change the expected output of pth_once.c, because the change has
altered the order of the (non-deterministic) output.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2825
