BUILD_ALL_DOCS is false; we've built them anyway). Delete them with 'make
distclean' too (and FAQ.txt).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10745
a manpage, and they're so simple I can't be bothered doing ones for them
(they don't even have sections in the manual).
Also fixed a few minor things relating to manpages.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10744
and created man pages for them. Renamed the XML files in the process for
consistency.
- Inlined cg-entities.xml into vg-entities.xml.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10742
- Added a manpage for ms_print.
- Added docs/xml/manpages-index.xml, which is just used as a convenient
single file to hang all the man pages off so they can be generated in a
single command.
- Added facility whereby manpage generation will attempt to find the
stylesheet in multiple places. This means I don't have to constantly edit
XSL_MAN_STYLE to build manpages on my machine.
- Changed vg-docs-path to start with $INSTALL instead of /usr/, because we
can't assume that's the installation dir.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10740
- Actually remove the dead docs/images/massif*.png files (this was meant to
happen in r10720).
- Inline $TOOL/docs/Makefile.am into $TOOL/Makefile.am for all 10 tools. 10
fewer Makefile.am files FTW!
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10721
- Remove roadmap.txt, as we haven't used it for a while and Bugzilla does it
better.
- Inline docs/{internals,images,xml,lib}/Makefile.am into docs/Makefile.am,
because they're very simple. Fewer Makefile.am files is good.
- Remove the dead docs/images/massif*.png files and all references to them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10720
- Match the ordering of the non-tool-specific options in the usage message
with the order in the user manual. As a result, we now always print
--alignment and --trace-malloc in the core's usage messages, which saves
malloc-replacing tools from doing it themselves (and brings it in line
with options that only apply to error-collecting tools).
- Improved the presentation of the Vex options with --help-debug.
- Removed documentation of -d in the manual because it's a debugging-only flag.
- Documented --read-var-info in the manual. This fixes bug 201169.
- Renamed --auto-run-dsymutil as --dsymutil and documented it in the usage
message.
- Fixed an XML error in manual-core-adv.xml.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10703
- Use "heap blocks" rather than "malloc'd blocks" as heap blocks covers
calloc, realloc, new, new[], memalign, etc.
- Used "GDB" and "GCC" throughout rather than "gcc" and "gdb".
- Made various tag uses more consistent.
- Greatly clarified the instructions on --xml=yes and its friends.
- Lots of other little improvements and fixes to out-of-date things and
Linux-centric things, mostly in Section 2.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10701
VALGRIND_{PRINTF,PRINTF_BACKTRACE,INTERNAL_PRINTF} were no longer appending
newlines. This meant that --trace-malloc=yes spewed everything onto a
single line, among other things.
Rather than adding the newline back in, I chose to offically change their
behaviour to not add the newlines, as this is more flexible (and the reason
for the underlying VG_(message) change). I updated all the relevant places
I could find.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10694
date from the man page.
Make the man page match the ordering in the user manual.
Put Nulgrind last in the user manual.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10662
line options. This commit changes them to all <option>.
Also make consistent how options with multiple names (eg. -h --help) are
shown.
Also, remove section describing --help and --version in Callgrind's chapter;
these aren't necessary and are presumably a hangover from when Callgrind was
a separate tool.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10659
docs, and the chapter/section numbering doesn't match the rest of the
numbering in the user manual.
Also change some of the names of the links in that file to match the
filename.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10653
- There were detailed descriptions of all the tools in the Quick Start
Guide, the Manual introduction, and the start of each tool chapter. To
avoid duplication/overlap, I removed these altogether from the Quick Start
Guide, and shortened them in the intro.
- Improved the description of what errors Memcheck can find.
- Made all tool chapters start with "Overview" section, for consistency.
- Made the "run with --tool=XXX" bit consistent in each tool chapter.
- Made all tool chapter titles match the description given when running them.
- Added BBV to the User Manual intro.
- Generally clarified, updated, and future-proofed various bits of text in
the Quick Start Guide and User Manual introduction.
Also:
- Changed Nulgrind's start-up description to "the minimal Valgrind tool".
- Fixed some punctuation in the usage message.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10652
following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364
please change these if you don't like what I've written, and merge the
changes to the 3.4.X branch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10215
I tried using 'svn merge' to do the merge but it did a terrible job and
there were bazillions of conflicts. So instead I just took the diff between
the branch and trunk at r10155, applied the diff to the trunk, 'svn add'ed
the added files (no files needed to be 'svn remove'd) and committed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10156
caused by heap corruption by the client. Also clarified the FAQ about this.
Also updated the FAQ about decoding failures a little.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9556
- It heavily refactors the code: uses better names for things, splits up
complex functions that behaved very differently depending on how they were
called, removes some redundancies, and generally makes it much simpler and
easier to follow.
- It adds lots of comments, both inline, and also a big explanatory one at
the top which makes it clear exactly how the leak checker works and also
exactly what is meant by definite, possible, and indirect leaks. It also
has some ideas for future improvements.
- All tabs have been converted to spaces.
It also improves the functionality:
- Previously if you did --leak-check=summary, indirect and suppressed
blocks were counted as definite leaks. Now they are done properly, and so
the summary results from --leak-check=summary match those from
--leak-check=yes.
- Previously, some possibly reachable blocks were miscategorised as
definitely reachable, because only the pointer to the block itself was
considered, not any preceding pointers in the chain. This is now fixed.
- Added memcheck/tests/leak-cases, which fully tests all the possible
combinations of directly/indirectly reachable and possibly/definitely
reachable.
And it improves the manual quite a bit, and the FAQ a little bit.
This doesn't fix the leak checker to handle MALLOCLIKE_BLOCK works that have
been taken from within malloc'd blocks, but I think I know how to do it and
hope to do so in a subsequent commit.
It also changes all instances of "<constant>memcheck</constant>" in the
Memcheck manual to "Memcheck", for consistency and because "Memcheck" is
easier to write. There's one similar case for DRD but I didn't change that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9330
'__libc_start_main', in Massif, m_debuginfo and m_stacktrace. As part of
this, --show-below-main is now visible to tools, and Massif pays attention
to it.
Improved the description of --show-below-main=yes in the manual.
Replaced some instances of "__libc_start_main" in the test *.exp files with
"(below main)", which is what will actually be seen. Also updated
scalar.stderr.exp*, which should make it get closer to actually passing.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9131
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
