- Added include/x86/: contains tool_arch.h, Makefile.am, .cvsignore.
- Added coregrind/x86/state.c. Contains some arch-specific code for dealing
with x86 registers -- eg. setting up the baseBlock, loading/saving the whole
register state. It is compiled into coregrind/x86/libarch.a and linked via
${VG_ARCH} with the core.
Relatedly, also added coregrind/x86/{core_arch.h,core_arch_asm.h}.
- Correspondingly abstracted the register state out of ThreadState. This
affected every place that touches registers, and there are a lot of them.
(Eventually all the register touching should be abstracted out in an
arch-neutral way, but not yet; one step at a time.)
- Added some declarations about register loading/saving functions to core.h;
all architectures will have to provide these functions.
- Rejigged the build system so that the arch-specific stuff is all done via
${VG_ARCH}, rather than naming e.g. x86/ directly. Appropriate -I arguments
are used so that all the headers are found, etc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2656
- removing the directories arch/x86-linux and arch/x86-freebsd, the contents of
which were never actually used.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2654
latter includes string.h on some older systems which then causes
problems when linux/fs.h includes linux/string.h due to it turning
various string functions into pre-processor macros.
This was the problem behind bug #87820 which actually had nothing to
do with gcc 2.95 and everything to do with the glibc and kernel
headers that the system had installed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2639
structure to match the address of the instruction in the client program
which caused the fault.
CCMAIL: 88115-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2623
rendezvous with another thread before the signal arrived then check
whether the rendezvous is now complete or we may deadlock.
CCMAIL: 77369-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2621
bit before "$(subdir)" has to specify the path from .in_place/ to the root.
It just so happened that $(top_builddir) was the same for all directories at
the same level in the hierarchy as .in_place/ (ie. one deep).
(I haven't bothered changing it in all the tool Makefile.am files, because I'll
do that when I factor out all their common bits into a single file, be it
before or after 2.2.0 is released.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2616
dist". This avoids the need to put it in "EXTRA_DIST", and saves a few lines
in all the docs Makefile.am files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2614
NOT allow Valgrind to work with 64-bit executables - only with 32-bit
executables on an AMD64 box.
VG_(valgrind_end) now has a slightly different meaning to all the other
VG_(*_end) vars -- ie. it names the last byte, whereas the others go
one byte past the end.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2606
glibc - it doesn't matter for valgrind as we only have one version and
by not versioning them we work no matter what version is asked for.
CCMAIL: 86289-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2605
__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
except it doesn't actually get built and so ex_main.c and the Makefile.am tend
to get out of date. Changed the docs to refer to Nulgrind as the example tool
for if you start writing a new one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2599
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
for the original function with RTLD_NEXT doesn't work then try looking
for the __libc_ version of the function the RTLD_DEFAULT instead.
The reason for this is that, contrary to the dlsym documentation, it
seems that RTLD_NEXT doesn't always seem to find the definition that
would have been used if it weren't for the override. This is particularly
common wihen libpthread is pulled in implicitly by a dependency from
another library.
This should hopefully fix bug #85658.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2595
- corrected a few mistakes, eg. when printing them out, in prototypes
- made printing of "%p(%s)" args consistent
- removed 'sizeof_struct_user_fpxregs_struct' from PRE(ptrace)/POST(ptrace)
- allowing for the two different versions of open()
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2591
of VgTs_WaitJoiner) as non-existent for the purposes of cancellation.
This ensures that pthread_cancel returns ESRCH instead of trying to
cancel the thread, which would lead to the thread cleanup code being
run twice.
CCMAIL: 86730-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2587
library - it seems that I misunderstood hom the versioning works and
a system looking for a GLIBC_PRIVATE version of the clock routines
would not find the GLIB_2.2.3 one even with the inheritance. It only
seemed to be working on glibc 2.3 systems because of the version
overrides in the source code, but it failed on glibc 2.2.5 systems.
The new approach is to explicity create two versions of the routines
in question, one with a version of GLIBC_2.2.3 and one with a version
of GLIBC_PRIVATE instead. This has been tested on six different systems
and appears to work everywhere.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2586
that it is called as soon as libpthread.so is loaded even if pthread_create
is never called.
This ensures that pthread_exit will work correctly, and I think will also
cure the famous memory leak in the pthread specifics for the main thread.
CCMAIL: 86730-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2584
