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
- 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
Rechecking the diff of r9080 on the mailing list, I thought
I forgot to replace "|" with "+" in one spot. But that was part
of not-used code, so it actually does not matter.
So better get rid of this code part at all (no need to backport ;-).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9081
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
that are memory offsets) with PtrdiffT; OffT should only be used for file
sizes and offsets.
Change Off64T from a ULong to a Long, as it should be. Replace some uses
of ULong in the address space manager with Off64T to match.
Also add a comment explaining the meanings of the basic types like Addr,
OffT, SizeT, etc.
Also fix the prototype for VG_(pread) -- the last arg is an OffT, not an
Int.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8959
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
OpenSuse 11.0 has glibc 2.8, which changed the assembly code for
runtime_resolve. This patch rearranges the code search such that
multiple variants can be scanned.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8841
This is a little tricky because
* we want to check directly at startup whether the output file
can be written, thus the file name is set at beginning.
* a fork changes the PID in the child, and thus (potentially) the
output file name has to be updated. This best is directly before
generating the profile dump.
* the child after fork needs to be controllable via callgrind_control.
The setup of the control interface needs the new file name, too.
The fix is to allow multiple calls of CLG(init_dumps), everytime the
output file name is needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8704
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
This obviously was already wrong in 3.2.x :-(
* Old --fn-recursion=... / --fn-caller=... options are called
--separate-recs=... / --separate-callers=... since quite some
time for consistency with e.g. --separate-threads=yes.
Error noted from bug 153335.
* Function specifications support wildcards since quite some time;
specification of a prefix only does not work, but the full
function has to match. This was needed to allow to specify 'foo'
without also specifying 'foo1'.
* The script 'callgrind' does not exist since merging into
valgrind.
* Rename callgrind from being a 'heavyweight' to a 'call graph'
profiler, similar to the description in the quick start overview.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7272
In dump.c, gcc complains that 'param max-stack-frame-growth' would be
exceeded, so remove 'inline' spec.
All other warnings are of the form 'call is unlikely and code size
would grow'. These aren't interesting. Remove -Winline.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7164
callgrind_control uses files /tmp/callgrind.info.* to be able to
locate running callgrind processes. These files can be read only by
the user which started callgrind. The callgrind_control script
did not check for "permission denied" on opening these files, which
resulted in some unexpected errors. Now, it is checked whether
the "open" was successful, and if not, we skip the according callgrind
process.
Fixes bug 149963.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6861
Prepend the file name of a source file with the directory
if that is available. This not only gets rid of problems with the
same file name used in different paths of a project, but lets
the annotation work out of the box without having to specify any
source directory.
Works both with callgrind_annotate and KCachegrind without any
changes there.
Inspired by Nick's change to cachegrind doing the same thing
in r6839 (and gets rid of a FIXME in the source)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6850
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
This hopefully makes the whole issue with cycles easier to understand.
And no, this does not get rid of the description of cycles, carefully
crafted by Julian ;-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6747
* Looks a little bit more like the Cachegrind manual
(at least in front)
* Removed the out-of-place general section about profiling
and gprof. Perhaps something like this can be put at
another place
* Notes about Callgrinds problems with call tracing on PPC
* Include usage of callgrind_annotate, and note its lack of
cycle detection
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6734
- 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
This introduces some macros to shorten the code for output of
strings to a file descriptor. I could use this a lot,
but this commit limits itself to the potential buffer overruns
(to ease backporting - provided we want to do this)
Heavy use of the macros probably blows up the code. Perhaps
it would be better to provide e.g. a VG_(write_str3) function
in the tool API.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6618
After the change in r6413, CLG_(run_thread) is called a
lot more often, increasing the polling overhead to check
for a callgrind command file (created by callgrind_control
for controlling a callgrind run in an interactive way).
This reduces the calls to only be done every 5000 BBs,
which gives a similar polling frequency as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6414
- Rename the event to 'thread_runstate'.
- Add arguments: pass also a boolean indicating whether the thread
is running or stopping, and a 64-bit int showing how many blocks
overall have run, so tools can make a rough estimate of workload.
The boolean allows tools to see threads starting and stopping.
Prior to this, de-schedule events were invisible to tools.
- Call the callback (hand the event to tools) just before client
code is run, and again immediately after it stops running. This
should give correct sequencing w.r.t posting of thread creation/
destruction events.
In order to make callgrind work without complex changes, I added a
simple impedance-matching function 'clg_thread_runstate_callback'
which hands thread-run events onwards to CLG_(thread_run).
Use this new 'thread_runstate' with care: it will be called before
and after every translation, which means it will be called ~500k
times in a startup of firefox. So the callback needs to be fast.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6413
