- In Cachegrind, abstract out x86-specific use of CPUID to find cache
configuration. Required adding a cachegrind/x86/ directory, and fiddling
a bit with the build system.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2698
__attribute((regparm(n))) with REGPARM(n) everywhere. REGPARM() is defined in
vg_skin.h, but will eventually be defined separately for each arch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2601
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
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
sometimes failed, causing an assertion failure. This is because the debug
info for the code address, which is used in the lookup,
can change -- eg. "myprint.c:myprint()" is found at instrumentation, but by the
time the invalidation occurs, it's changed to "myprint.c:???". So it now falls
back to a slow exhaustive search of the table.
This was causing cachegrind/tests/dlclose to fail, and should hopefully fix
bug #72781.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2218
Patch to improve SSE/SS2 support
This patch should implement most of the missing SSE/SSE2 opcodes. About
the only ones it doesn't do are the MASKMOVxxx ones as they are quite
horrible and involved an implicit reference to EDI so I need to think
about them a bit more.
The patch also includes a set of tests for the MMX/SSE/SSE2 opcodes to
validate that they have the same effect under valgrind as they do when
run normally. In one or two cases this wasn't actually the case even
for some of the implemented opcodes, so I fixed those as well ;-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2202
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2027
to inline. This is needed to get a warning-free compilation on 3.3.1.
It seems we had "inline" on some pretty huge functions in places.
Also it appears gcc-3.3.1 won't inline a function call in a tail call
position, reasonably enough. I assume in that case it prefers to
create a tailcall to the callee, rather than inlining it.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1907
for vendor_id "CentaurHauls", which is the VIA string (reflecting its
design heritage). Currently pretend to be something like a VIA Nehemiah.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1897
number, will print it with commas delimiting it. Very useful when printing
large numbers.
Using it, was able to remove the wretched commify() function from Cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1869
this, which meant that if a shorter file of the same name was written, the old
contents past the new end would remain, which would be bad. Had (probably)
never happened because the <pid> suffix makes it very unlikely for filenames to
be reused.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1777
(prerelease) (SuSE Linux)") seems to complain about signed-vs-unsigned
comparisons, when -Wall is on. This commit fixes (most of) those
complaints.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1638
the output file wouldn't get written. No longer creating the file at startup
and then writing it at the end; just writing it at the end. Also recording
the start directory at the start so that the output ends up in it even if the
program does change directory.
Had to add VG_(getcwd)() to vg_mylibc.c for this.
Added a regression test for it too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1576
for skins.
Changed lackey to print out the exit code.
Changed AUTOMAKE_OPTIONS back to 1.5 (whoops)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1538
overview
-----------------------------------------------------------------------------
Previously Valgrind had its own versions of malloc() et al that replaced
glibc's. This is necessary for various reasons for Memcheck, but isn't needed,
and was actually detrimental, to some other skins. I never managed to treat
this satisfactorily w.r.t the core/skin split.
Now I have. If a skin needs to know about malloc() et al, it must provide its
own replacements. But because this is not uncommon, the core provides a module
vg_replace_malloc.c which a skin can link with, which provides skeleton
definitions, to reduce the amount of work a skin must do. The skeletons handle
the transfer of control from the simd CPU to the real CPU, and also the
--alignment, --sloppy-malloc and --trace-malloc options. These skeleton
definitions subsequently call functions SK_(malloc), SK_(free), etc, which the
skin must define; in these functions the skin can do the things it needs to do
about tracking heap blocks.
For skins that track extra info about malloc'd blocks -- previously done with
ShadowChunks -- there is a new file vg_hashtable.c that implements a
generic-ish hash table (using dodgy C-style inheritance using struct overlays)
which allows skins to continue doing this fairly easily.
Skins can also replace other functions too, eg. Memcheck has its own versions
of strcpy(), memcpy(), etc.
Overall, it's slightly more work now for skins that need to replace malloc(),
but other skins don't have to use Valgrind's malloc(), so they're getting a
"purer" program run, which is good, and most of the remaining rough edges from
the core/skin split have been removed.
-----------------------------------------------------------------------------
details
-----------------------------------------------------------------------------
Moved malloc() et al intercepts from vg_clientfuncs.c into vg_replace_malloc.c.
Skins can link to it if they want to replace malloc() and friends; it does
some stuff then passes control to SK_(malloc)() et al which the skin must
define. They can call VG_(cli_malloc)() and VG_(cli_free)() to do the actual
allocation/deallocation. Redzone size for the client (the CLIENT arena) is
specified by the static variable VG_(vg_malloc_redzone_szB).
vg_replace_malloc.c thus represents a kind of "mantle" level service.
To get automake to build vg_replace_malloc.o, had to resort to a similar trick
as used for the demangler -- ask for a "no install" library (which is never
used) to be built from it.
Note that all malloc, calloc, realloc, builtin_new, builtin_vec_new, memalign
are now aware of --alignment, when running on simd CPU or real CPU.
This means the new_mem_heap, die_mem_heap, copy_mem_heap and ban_mem_heap
events no longer exist, since the core doesn't control malloc() any more, and
skins can watch for these events themselves.
This required moving all the ShadowChunk stuff out of the core, which meant
the sizeof_shadow_block ``need'' could be removed, yay -- it was a horrible
hack. Now ShadowChunks are done with a generic HashTable type, in
vg_hashtable.c, which skins can "inherit from" (in a dodgy C-only fashion by
using structs with similar layouts). Also, the free_list stuff was all moved
as a part of this. Also, VgAllocKind was moved out of core into
Memcheck/Addrcheck and renamed MAC_AllocKind.
Moved these options out of core into vg_replace_malloc.c:
--trace-malloc
--sloppy-malloc
--alignment
The alternative_free ``need'' could go, too, since Memcheck is now in complete
control of free(), yay -- another horribility.
The bad_free and free_mismatch events could go too, since they're now not
detected by core, yay -- yet another horribility.
Moved malloc() et al wrappers for Memcheck out of vg_clientmalloc.c into
mac_malloc_wrappers.c. Helgrind has its own wrappers now too.
Introduced VG_USERREQ__CLIENT_CALL[123] client requests. When a skin function
is operating on the simd CPU, this will call a given function and run it on the
real CPU. The macros VG_NON_SIMD_CALL[123] in valgrind.h present a cleaner
interface to actually use. Also introduce analogues of these that pass 'tst'
from the scheduler as the first arg to the called function -- needed for
MC_(client_malloc)() et al.
Fiddled with USERREQ_{MALLOC,FREE} etc. in vg_scheduler.c; they call
SK_({malloc,free})() which by default call VG_(cli_malloc)() -- can't call
glibc's malloc() here. All the other default SK_(calloc)() etc. instantly
panic; there's a lock variable to ensure that the default SK_({malloc,free})()
are only called from the scheduler, which prevents a skin from forgetting to
override SK_({malloc,free})(). Got rid of the unused USERREQ_CALLOC,
USERREQ_BUILTIN_NEW, etc.
Moved special versions of strcpy/strlen, etc, memcpy() and memchr() into
mac_replace_strmem.c -- they are only necessary for memcheck, because the
hyper-optimised normal glibc versions confuse it, and for memcpy() etc. overlap
checking.
Also added dst/src overlap checks to strcpy(), memcpy(), strcat(). They are
reported not as proper errors, but just with single line warnings, as for silly
args to malloc() et al; this is mainly because they're on the simulated CPU
and proper error handling would be a pain; hopefully they're rare enough to
not be a problem. The strcpy check is done after the copy, because it would
require counting the length of the string beforehand. Also added strncpy() and
strncat(), which have overlap checks too. Note that addrcheck doesn't do
overlap checking.
Put USERREQ__LOGMESSAGE in vg_skin.h to do the overlap check error messages.
After removing malloc() et al and strcpy() et al out of vg_clientfuncs.c, moved
the remaining three things (sigsuspend, VG_(__libc_freeres_wrapper),
__errno_location) into vg_intercept.c, since it contains things that run on the
simulated CPU too. Removed vg_clientfuncs.c altogether.
Moved regression test "malloc3" out of corecheck into memcheck, since corecheck
no longer looks for silly (eg. negative) args to malloc().
Removed the m_eip, m_esp, m_ebp fields from the `Error' type. They were being
set up, and then read immediately only once, only if GDB attachment was done.
So now they're just being held in local variables. This saves 12 bytes per
Error.
Made replacement calloc() check for --sloppy-malloc; previously it didn't.
Added "silly" negative size arg check to realloc(), it didn't have one.
Changed VG_(read_selfprocmaps)() so it can parse the file directly, or from a
previously read buffer. Buffer can be filled with the new
VG_(read_selfprocmaps_contents)(). Using this at start-up to snapshot
/proc/self/maps before the skins do anything, and then parsing it once they
have done their setup stuff. Skins can now safely call VG_(malloc)() in
SK_({pre,post}_clo_init)() without the mmap'd superblock erroneously being
identified as client memory.
Changed the --help usage message slightly, now divided into four sections: core
normal, skin normal, core debugging, skin debugging. Changed the interface for
the command_line_options need slightly -- now two functions, VG_(print_usage)()
and VG_(print_debug_usage)(), and they do the printing themselves, instead of
just returning a string -- that's more flexible.
Removed DEBUG_CLIENTMALLOC code, it wasn't being used and was a pain.
Added a regression test testing leak suppressions (nanoleak_supp), and another
testing strcpy/memcpy/etc overlap warnings (overlap).
Also changed Addrcheck to link with the files shared with Memcheck, rather than
#including the .c files directly.
Commoned up a little more shared Addrcheck/Memcheck code, for the usage
message, and initialisation/finalisation.
Added a Bool param to VG_(unique_error)() dictating whether it should allow
GDB to be attached; for leak checks, because we don't want to attach GDB on
leak errors (causes seg faults). A bit hacky, but it will do.
Had to change lots of the expected outputs from regression files now that
malloc() et al are in vg_replace_malloc.c rather than vg_clientfuncs.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1524
the same as that for FPU instructions. That is, regard the MMX state
(which is the same as the FPU state) opaquely, and every time we
need to do a MMX instruction, move the simulated MMX state into the
real CPU, do the instruction, and move it back. JeremyF's optimisation
to minimise FPU saves/restores applies automatically here.
So, this scheme is simple. It will cause memcheck to complain bitterly
if uninitialised data is copied through the MMX registers, in the same
way that memcheck complains if you move uninit data through the FPU
registers. Whether this turns out to be a problem remains to be seen.
Most instructions are done, and doing the rest is easy enough, I just
need people to send test cases so I can do them on demand.
(Core) UCode has been extended with 7 new uinstrs:
MMX1 MMX2 MMX3
-- 1/2/3 byte mmx insns, no references to
integer regs or memory, copy exactly to the output stream.
MMX_MemRd MMX_MemWr
-- 2 byte mmx insns which read/write memory and therefore need
to have an address register patched in at code generation
time. These are the analogues to FPU_R / FPU_W.
MMX_RegRd MMX_RegWr
-- These have no analogues in FPU land. They hold 2 byte insns
which move data to/from a normal integer register (%eax etc),
and so this has to be made explicit so that (1) a suitable
int reg can be patched in at codegen time, and (2) so that
memcheck can do suitable magic with the V bits going into/
out of the MMX regs.
Nulgrind (ok, this is a nop, but still ...) and AddrCheck's
instrumenters have been extended to cover these new UInstrs. All
others (cachesim, memcheck, lackey, helgrind, did I forget any)
abort when they see any of them. This may be overkill but at least
it ensures we don't forget to implement it in those skins.
[A bad thing would be that some skin silently passes along
MMX uinstrs because of a default: case, when it should actually
do something with them.]
If this works out well, I propose to backport this to 2_0_BRANCH.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1483
Make file_err() not abort the current process; recover and keep
going instead. This fixes a problem running OpenOffice on cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1362
