Problem was that the malloc-replacing tools (memcheck, addrcheck, massif,
helgrind) would assert if a too-big malloc was attempted. Now they return 0 to
the client. I also cleaned up the code handling heap-block-metadata in Massif
and Addrcheck/Memcheck a little.
This exposed a nasty bug in VG_(client_alloc)() which wasn't checking if
find_map_space() was succeeding before attempting an mmap(). Before I added
the check, very big mallocs (eg 2GB) for Addrcheck were overwriting the client
space at address 0 and causing crashes.
Added a regtest to all the affected skins for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2462
scheme, there are two main structures:
1. The CC table holds a cost centre (CC) for every distinct source code
line, as found using debug/symbol info. It's arranged by files, then
functions, then lines.
2. The instr-info-table holds certain important pieces of info about
each instruction -- instr_addr, instr_size, data_size, its line-CC.
A pointer to the instr's info is passed to the simulation functions,
which is shorter and quicker than passing the pieces individually.
This is nice and simple. Previously, there was a single data structure
(the BBCC table) which mingled the two purposes (maintaining CCs and
caching instruction info). The CC stuff was done at the level of
instructions, and there were different CC types for different kinds of
instructions, and it was pretty yucky. The two simple data structures
together are much less complex than the original single data structure.
As a result, we have the following general improvements:
- Previously, when code was unloaded all its hit/miss counts were stuck
in a single "discard" CC, and so that code would not be annotated. Now
this code is profiled and annotatable just like all other code.
- Source code size is 27% smaller. cg_main.c is now 1472 lines, down
from 2174. Some (1/3?) of this is from removing the special handling
of JIFZ and general compaction, but most is from the data structure
changes. Happily, a lot of the removed code was nasty.
- Object code size (vgskin_cachegrind.so) is 15% smaller.
- cachegrind.out.pid size is about 90+% smaller(!) Annotation time is
accordingly *much* faster. Doing cost-centres at the level of source
code lines rather than instructions makes a big difference, since
there's typically 2--3 instructions per source line. Even better,
when debug info is not present, entire functions (and even files) get
collapsed into a single "???" CC. (This behaviour is no different
to what happened before, it's just the collapsing used to occur in the
annotation script, rather than within Cachegrind.) This is a huge win
for stripped libraries.
- Memory consumption is about 10--20% less, due to fewer CCs.
- Speed is not much changed -- the changes were not in the intensive
parts, so the only likely change is a cache improvement due to using
less memory. SPEC experiments go -3 -- 10% faster, with the "average"
being unchanged or perhaps a tiny bit faster.
I've tested it reasonably thoroughly, it seems extremely similar result
as the old version, which is highly encouraging. (The results aren't
quite the same, because they are so sensitive to memory layout; even
tiny changes to Cachegrind affect the results slightly.)
Some particularly nice changes that happened:
- No longer need an instrumentation prepass; this is because CCs are not
stored grouped by BB, and they're all the same size now. (This makes
various bits of code much simpler than before).
- The actions to take when a BB translation is discarded (due to the
translation table getting full) are much easier -- just chuck all the
instr-info nodes for the BB, without touching the CCs.
- Dumping the cachegrind.out.pid file at the end is much simpler, just
because the CC data structure is much neater.
Some other, specific changes:
- Removed the JIFZ special handling, which never did what it was
intended to do and just complicated things. This changes the results
for REP-prefixed instructions very slightly, but it's not important.
- Abbreviated the FP/MMX/SSE crap by being slightly laxer with size
checking -- not an issue, since this checking was just a pale
imitation of the stricter checking done in codegen anyway.
- Removed "fi" and "fe" handling from cg_annotate, no longer needed due
to neatening of the CC-table.
- Factorised out some code a bit, so fewer monolithic slabs,
particularly in SK_(instrument)().
- Just improved formatting and compacted code in general in various
places.
- Removed the long-commented-out sanity checking code at the bottom.
Phew.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2458
skiplist implementation. Also, fix a bug which allocated way too much memory
for the list head (found by Nick).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2451
directory from the source tree. This resolves bug 83040.
Based on patch from Ralf Wildenhues <Ralf.Wildenhues@gmx.de>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2450
cause the stack to be marked as executable in order for them to work.
All assembler files have also had a declaration added so that the
object they generate will be marked as not needing an executable stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2446
stack attribute related functions work properly as it seems to be a
sensible thing to improve even if it isn't enough to get the JVM running
under valgrind now.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2444
As a result, can now mmap much more memory (eg. for Memcheck, 850MB up from
250MB, for Nulgrind 1750MB up from 700MB). The heap is smaller, but that
doesn't matter much, since programs use brk() directly only rarely, and
malloc() falls back on mmap() if brk() fails anyway.
Also changed the debug info printing for memory layout slightly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2441
the current reserved area, which effectively acts as a hard limit. The
setrlimit system call now simply updates the emulated limits as best
as possible - the hard limit is not allowed to move at all and just
returns EPERM if you try and change it.
This should stop reductions in the soft limit causing assertions when
valgrind tries to allocate descriptors from the reserved area.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2440
--logfile-fd --> --log-fd
--logfile --> --log-file
--logsocket --> --log-socket
to be consistent with each other and other options (esp. --input-fd). Also
renamed some related variables. The old names still work, for backwards
compatibility, but they're not documented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2429
the execve system call if the envp pointer is null as it causes
valgrind to die with a segmentation fault.
CCMAIL: 83573-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2427
improve the checking of other interface related ioctls.
Based in part on a patch from Jim McDonald <jim@mcdee.net> supplied
as a fix for bug #83344.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2424
to query the CPU characteristics as the use of four implicit registers
causes havoc when GCC tries to inline and optimise the assembler.
Fix to bug #79696.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2421
- If no tool is specified, V now gives a short message and a list of
available tools. This was meant to happen previously, but a bug prevented
it from working properly; it gave the usage message instead.
- If a bad option is given, V now gives a short message rather than the full
--help. This make V consistent with all other programs I looked at.
- Now returning 0 when you do 'valgrind --help' and 'valgrind --version'
as other programs do.
- Removed VG_(startup_logging)() and VG_(shutdown_logging)() as they were
empty and have been for a long time (always?).
- Added various tests for these scenarios. Had to change the regtest
script slightly to allow for malformed command lines.
This addresses bug (wishlist) #82999.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2418
