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
run, though. There are lots of stubs to be filled in. (The asm ones currently
just have "swi" in them, which seems to cause seg faults.)
Also, some of the macros are decided dubious, especially:
ARCH_* are bogus
SYSCALL_RET is bogus
PLATFORM_SET_SYSCALL_RESULT is bogus
not sure about SET_SYSCALL_RETVAL
FIRST_STACK_FRAME et al -- bogus?
VG_MAX_JUMPS ?
And in stage2.lds, the 0x8048000 is almost certainly wrong
This required some tweakings of the core:
- some of the vki_*.h kernel types were fixed up
- had to disable the AM_PROG_CC_C_O macro in configure.in, because automake
(autoconf?) didn't like it...
- some "#ifdef __x86__" guards were introduced, for nasty x86 things I don't
yet know how to factor out (trampoline page muck, sysinfo page muck).
- fixed a minor stupidity in vg_proxylwp.c.
- moved the ptrace wrapper into the x86-linux part
- had to change the intercept mangling scheme, to use 'J' instead of '$' as the
escape char because GCC didn't like '$'. This is all very dubious, and only
works because none of our intercepted symbols contains a 'J'. To be fixed up
ASAP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3120
arg is only used if the 2nd arg has particular values, so we were
getting false positives. This commit makes the wrappers smarter to
account for this. I updated the reg test too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3080
Also now checking the return value of every syscall in scalar, to make sure
that they (mostly) fail as expected. Because occasionally one would succeed
unexpectedly and unaddressable memory would be marked as addressable, and
things would go haywire. (The fact that the wrapper sets the memory as
addressable in these cases is a bug with the relevant wrappers; I'll fix them
later.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3023
the ioctls complained about in bug 93096 as well as one that came up
on the mailing list a few weeks ago.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2982
- 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
