Some of our option processing code uses it. This means that eg.
'--log-fd=9xxx' logs to fd 9, and '--log-fd=blahblahblah' logs to 0 (because
atoll() returns 0 if the string doesn't contain a number!)
It turns out that most of our option processing uses VG_(strtoll*) instead
of VG_(atoll). The reason that not all of it does is that the
option-processing macros are underpowered -- they currently work well if you
just want to assign the value to a variable, eg:
VG_BOOL_CLO(arg, "--heap", clo_heap)
else VG_BOOL_CLO(arg, "--stacks", clo_stacks)
else VG_NUM_CLO(arg, "--heap-admin", clo_heap_admin)
else VG_NUM_CLO(arg, "--depth", clo_depth)
(This works because they are actually an if-statement, but it looks odd.)
VG_NUM_CLO uses VG_(stroll10). But if you want to do any checking or
processing, you can't use those macros, leading to code like this:
else if (VG_CLO_STREQN(9, arg, "--log-fd=")) {
log_to = VgLogTo_Fd;
VG_(clo_log_name) = NULL;
tmp_log_fd = (Int)VG_(atoll)(&arg[9]);
}
So this commit:
- Improves the *_CLO_* macros so that they can be used in all circumstances.
They're now just expressions (albeit ones with side-effects, setting the
named variable appropriately). Thus they can be used as if-conditions,
and any post-checking or processing can occur in the then-statement. And
malformed numeric arguments (eg. --log-fd=foo) aren't accepted. This also
means you don't have to specify the lengths of any option strings anywhere
(eg. the 9 in the --log-fd example above). The use of a wrong number
caused at least one bug, in Massif.
- Updates all places where the macros were used.
- Updates Helgrind to use the *_CLO_* macros (it didn't use them).
- Updates Callgrind to use the *_CLO_* macros (it didn't use them), except
for the more esoteric option names (those with numbers in the option
name). This allowed getUInt() and getUWord() to be removed.
- Improves the cache option parsing in Cachegrind and Callgrind -- now uses
VG_(strtoll10)(), detects overflow, and is shorter.
- Uses INT instead of NUM in the macro names, to distinguish better vs. the
DBL macro.
- Removes VG_(atoll*) and the few remaining uses -- they're wretched
functions and VG_(strtoll*) should be used instead.
- Adds the VG_STREQN macro.
- Changes VG_BINT_CLO and VG_BHEX_CLO to abort if the given value is outside
the range -- the current silent truncation is likely to cause confusion as
much as anything.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9255
built. This worked fine on the x86/Linux and AMD64/Linux but broke
ppc*/Linux. This commit fixes the problem. Thanks to Bart for spotting it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9222
- Created Makefile.tool-tests.am, put standard AM_CFLAGS et al for tests in
it.
- A number of tests are shared between Helgrind and DRD. They used to be
built in both directories. Now they are only built in helgrind/tests/,
and the DRD .vgtest files just point to the executable in helgrind/tests/.
Most of these (about 30) had the source files in helgrind/tests/; I moved
the three that were in drd/tests/ into helgrind/tests/ for consistency.
- Fixed rwlock_test, which was failing to run due to a wrong name in the
.vgtest file.
- Removed remnants of unused 'hello' test for Memcheck.
- Avoided redundant flag specification in various places, esp.
memcheck/tests/Makefile.am.
- Removed unnecessary _AIX guards in some Linux-only tests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9202
The number of sets, ie. number of cache lines divided by associativity,
and the cache line size still have to be powers of two.
This change is needed for default cache parameters used on some Intel
Core 2 and Atom processors.
Includes cachegrind manual update and explicit tests with 24KB D1/3MB L2
Reverts addition of 6MB warning to {cachegrind,callgrind}/tests/filter_stderr
Backporting to VALGRIND_3_4_BRANCH needs r8912
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9080
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
arch/OS/platform-specific tool test dirs, instead writing it by hand.
This is important because up until now if we had any arch-specific test
dirs, we needed such dirs for all archs. Now that we also have
OS-specific and platform-specific test dirs, we don't want to have
(mostly) empty dirs for every arch/OS/platform.
- Correspondingly, removed several empty directories under memcheck/tests/
and cachegrind/tests that are no longer needed.
- Also removed VG_ARCH_ALL from configure.in.
- Also used an arch-specific guard rather than a platform-specific one where
appropriate in cachegrind/tests/Makefile.am.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9017
trunk/memcheck/tests/vcpu_bz2.c
trunk/memcheck/tests/vcpu_bz2.vgtest
vcpu_bz2.c was (I think) an "svn copy" of perf/bz2.c. Because it's a
copy, the two can get out of sync, which was a problem with Greg
Parker's Darwin patch. So we remove vcpu_bz2.c, and make
vcpu_bz2.vgtest invoke perf/bz2 directly.
trunk/cachegrind/tests/wrap5.c
trunk/cachegrind/tests/Makefile.am
trunk/cachegrind/tests/wrap5.vgtest
wrap5.c was likewise an "svn copy" of memcheck/tests/wrap5.c, so we do
the equivalent thing with it.
trunk/Makefile.am
Fix a typo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8919
cachegrind/tests/filter_stderr
Filter out an additional warning, so the tests pass on machines with a
6MB L2 cache.
cachegrind/cg-x86.c
cachegrind/cg-amd64.c
These two files were almost identical. cg-amd64.c now just #includes
cg-x86.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8912
processors. These come from sandpile.org as the current version
of Intel's Application Note 485 doesn't have them yet.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8891
relatively minor extensions to m_debuginfo, a major overhaul of
m_debuginfo/readdwarf3.c to get its space usage under control, and
changes throughout the system to enable heap-use profiling.
The majority of the merged changes were committed into
branches/PTRCHECK as the following revs: 8591 8595 8598 8599 8601 and
8161.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8621
wrote into the parent's output file even if %p was specified.
Josef, I think Callgrind does not have this bug, but you might want to say
something about forking in the manual, as I have done for Massif and
Cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8154
somewhat to move less relevant material out of the way to some extent.
The main changes are:
* Update date and version info
* Mention other tools in the quick-start guide
* Document --child-silent-after-fork
* Rearrange order of sections in the Valgrind Core chapter, to move
advanced stuff (client requests) to the end, and compact stuff
relevant to the majority of users towards the front
* Move MPI debugging stuff from the Core manual (a nonsensical place
for it) to the Memcheck chapter
* Update the manual's introductory chapter a bit
* Connect up new tech docs summary page, and disconnect old and
very out of date valgrind/memcheck tech docs
* Add section tags to the Cachegrind manual, to stop xsltproc
complaining about their absence
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7199
interface and provides full power; and "OSetWord_", which is an
easier-to-use interface for if you just want to store words.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6841
VG_(record_startup_wd) which records the working directory at startup,
and VG_(get_startup_wd) which later tells you what value was recorded.
This works because all uses of VG_(getcwd) serve only to record the
directory at process start anyway. The motivation is that AIX does
not support sys_getcwd directly, so it's easier for the launcher to
ship in the required value using an environment variable. On Linux
sys_getcwd is used as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6764
--branch-sim=yes is specified, Cachegrind simulates a simple indirect
branch predictor and a conditional branch predictor. The latter
considers both the branch instruction's address and the behaviour of
the last few conditional branches. Return stack prediction is not
modelled.
The new counted events are: conditional branches (Bc), mispredicted
conditional branches (Bcm), indirect branches (Bi) and mispredicted
indirect branches (Bim). Postprocessing tools (cg_annotate, cg_merge)
handle the new events as you would expect. Note that branch
simulation is not enabled by default as it gives a 20%-25% slowdown,
so you need to ask for it explicitly using --branch-sim=yes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6733
- extend some to 2007
- use njn@valgrind.org instead of njn25@cam.ac.uk
- use "tool" instead of "skin"
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6703
precisely the name of the profile data file it should use (instead of
assuming cachegrind.out.<pid> where <pid> is specified by the --<pid>
flag). The old mechanism is still supported though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6573
basename to be something other than "cachegrind.out".
* Observe the core-supplied --log-file-qualifier, if specified,
in creation of output file names.
* To make the above work, move most of the stuff in cg_pre_clo_init
into cg_post_clo_init, so that the core's determination of the
log file qualifier, if any, is done by the time cachegrind comes
to process its arguments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6572
On Intel processors, CPUIDs cache parameter code 0x49 is
reused both for L2 and L3 parameters.
Thanks to Ulrich Drepper.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6369
Cachegrind docs.
Removed the Cachegrind tech docs, because they're so out of date to be
useless. My PhD dissertation gives a much better description of how
Cachegrind works. (I mentioned this in the Cachegrind user manual.) The
only still-useful part of Cachegrind's tech docs, the output file format
description, I moved into the Cachegrind user manual.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6332