$INSTALL/<platform>/<filename>, they go to $INSTALL/<filename>-<platform>.
These filenames match those built in the build tree, and so simplifies the
build system signficantly and avoids the horrible sed renamings that were
previously required. This will also help greatly with the treatment of
.dSYM debug directories in the DARWIN branch.
Files affected include:
- preload libraries such as vgpreload_core-<platform>.so and
libmpiwrap-<platform>.so
- libraries such as libcoregrind_<platform>.a
- executables such as memcheck-<platform>
I updated the manual and added a note to the NEWS file about the change,
because it will affect a small number of users.
I did my best to update the AIX launcher/initimg correctly, but it hasn't
been tested.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9135
clearer what they mean:
- They all have VGCONF_ prefixes now, to indicate they come out of
configure.in (and are clearly distinguished from the VGA_/VGO_/VGP_
#defines passed in to C files).
- The ones that refer to the primary *or* secondary platform have _INCLUDES_
in them.
- The ones that are in all-caps have a _CAPS suffix.
So, for example, what was VGP_X86_LINUX is now
VGCONF_PLATFORMS_INCLUDE_X86_LINUX, which is more verbose but also a lot
clearer. The names of the #defines used in the C files (VGA_x86, VGO_linux,
etc) are unchanged.
cputest.c: changed to reflect the Valgrind installation's capabilities,
rather than the machine's capabilities. In particular, if
--enable-only32bit is used on a 64-bit machine, then this program will claim
to only support 32-bits. Also use the VGA/VGO/VGP macros which are clearer
than the __i386__ ones. (This is partially merged from the DARWIN branch.)
configure.in: clean up the comments, distinguish different sections more
clearly, and generally make it more readable.
valgrind.pc.in: try to make this more accurate. I doubt anyone's using it.
It doesn't appear to be set up to handle dual-architecture builds.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9031
the DARWIN branch easier later.
- Remove the disabled vgtest_ume test, it's very unlikely it'll ever work
again.
- Move VG_(find_auxv) to initimg-linux.c, the only place it's used, and make
it static.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9004
matching, in the function VG_(generic_match). Patterns to be matched
against may contain only '*'-style wildcards (matches any number of
elements, we don't care what they are), '?' wildcards (matches exactly
one element, we don't care what it is) and literal elements.
It is totally abstractified, in the sense that the pattern and input
arrays may be arrays of anything. The caller provides enough
information so that VG_(generic_match) can step along both arrays, and
can ask the questions "is this pattern element a '*' ?", "is this
pattern element a '?' ?", and "does this pattern element match an
input element ?".
The existing function VG_(string_match) is reimplemented using
VG_(generic_match), although the ability to escape metacharacters in
the pattern string is removed -- I don't think it was ever used.
In m_errormgr, matching of suppression stacks (including wildcard
"..." lines) against error stacks is re-implemented using
VG_(generic_match).
Further detailed comments are in m_seqmatch.h and pub_tool_seqmatch.h.
A negative side effect is that VG_(string_match) will be much slower
than before, due to the abstractification. It may be necessary to
reimplement a specialised version later.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8816
which is also indexed by UWord. This can be used as a replacement for
WordFM with unboxed keys, when the key ranges are dense. It is
implemented as a 256-way radix tree (4-deep on 32-bit platforms,
8-deep on 64-bit platforms).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8806
helgrind/ into the core. It's just too darn useful to not be in the
core. There is some overlap in functionality between OSet and WordFM,
but OSet is more space efficient in some circumstances, whereas WordFM
is easier to use and a bit more flexible in some cases.
Also in this new module (m_wordfm) is a type WordBag, build on top of
WordFM. This provides Multiset of UWords functionality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8524
Problem is that --help etc are handled by the tool exe. But a
ptrace-based launch scheme can't run "no program" if the user just
types "valgrind --help" because the launcher depends on starting the
client first and only then attaching valgrind to it using ptrace. So
instead provide a dummy do-nothing program to run when no program is
specified. m_main notices this and acts as if there really had been
no program specified.
This has no effect at all on Linux/ELF program launching.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6653
abstraction implemented independently in several places in the code
base (bad!). This commit moves into public view a generic
implementation of it which has been lurking in readxcoff.c for some
time. Currently nothing uses it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6614
Mostly commented out the unused stuff relating to ThreadErrs and MutexErrs,
which no longer exist.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6399
Makefile.am changes for AIX5. Almost all boilerplate stuff fitting in
with the existing factorisation scheme. The only change of interest
is that configure.in now generates automake symbols of name
VGP_platform and VGO_os, whereas previously it just made VG_platform
which was a bit inconsistent with the VGP/VGO/VGA scheme used in C
code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6242
interface, except for the syscall numbers, into that. Mostly this
means moving include/vki-*.h to include/vki/vki-*.h.
include/pub_tool_basics.h previously dragged in the entire kernel
interface. I've done away with that, so that modules which need to
see the kernel interface now have to include pub_{core,tool}_vki.h
explicitly. This is why there are many modified .c files -- they have
all acquired an extra #include line.
This certainly breaks all platforms except x86. Will fix shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6225
distinction between primary and secondary build targets, and (2) make
it independent of the default behaviour of gcc (iow, what gcc does
when you specify neither -m32 nor -m64).
As a result, an out-of-the-box build on ppc64-linux now builds a
system which is basically for 64-bit PowerPC, but also has the ability
to run 32-bit ppc-linux binaries (exactly the same arrangement as you
get when building on amd64-linux).
There are various twists and turns. multiple-architectures.txt is
updated all the gory details.
This will break amd64 builds until such time as
<tool>/tests/{amd64,x86}/Makefile.am are fixed up (shortly).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5493
system that allows multiple copies of valgrind to be built so that we
can build both x86 and amd64 versions of the tools on amd64 machines.
The launcher is then modified to look at the program being run and
decide which tool to use to run it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5027
was in the sigframe module has been moved into the coredump module
where it belongs and things fixed up to compiler again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4970
with respect to syscalls. It is detailed and comprehensive but does
not offer a way to deal with minor deviations in behaviour from the
vanilla kernel sources, either due to running a hacked kernel or
running a vanilla kernel with a custom kernel module loaded.
This commit adds a flexible way to handle such cases without polluting
the vanilla handler syswrap-*.c files or their supporting vki_*.h
header files. For each OS, a syswrap-OS-variants.c file is added,
containing wrappers for variants of OS. A new command line flag
--kernel-variants= carries a comma separated list of variant names
that apply to the current run. There are no other changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4873
as requested by Greg Parker. (The ppc32/Darwin dispatch loop is
different to the ppc32/Linux one, for example.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4843
and so is not part of a module cycle. This requires a moderately
grotty hack of passing a continuation-function pointer in a global
variable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4806
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
