changed to name the last byte in Valgrind's section, rather than one past the
last byte. This was because the last byte is 0xffffffff, and so one past gave
0x0, which screwed things up.
However, when this change was made, all the places where VG_(valgrind_end) is
used weren't adjusted appropriately. So this commit makes those adjustments.
It also renames the variable as VG_(valgrind_last), which makes the difference
between it and the other VG_(*_end) variables much clearer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2672
__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
lower than that of any existing segment, it got it wrong due to the confusing
SkipList API. I wonder how many more bugs like that there are...?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2596
requires padding of the address space around calls to io_setup in order
to constrain the kernel's choice of address for the I/O context.
Based on patch from Scott Smith <scott-kde@gelatinous.com> with various
enhancements, this fixes bug #83060.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2485
1. It simplifies various things a bit.
2. Valgrind/tools will run out of memory later than currently in many
circumstances. This is good news esp. for Calltree.
Some things were going in V's 128MB heap, and some were going in V's 128MB map
segment. Now all these things are going into a single 256MB map segment.
stage2 has been moved down to 0xb0000000, the start of the 256MB map segment.
The .so files needed by it are placed at 0xb1000000 (that's the map_base).
This required some bootstrapping at startup for memory -- we need to allocate
memory to create the segments skip-list which lets us allocate memory...
solution was to make the first superblock allocated a special static one.
That's pretty simple and enough to get things going.
Removed vg_glibc.c which wasn't doing anything anyway.
Removed VG_(brk) and associated stuff, made all the things that were calling it
call VG_(mmap)() instead.
Removed VG_(valgrind_mmap_end) which was no longer needed.
Rejigged the startup order a bit as necessary.
Moved an important comment from ume.c to vg_main.c where it should be.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2482
add a segment mapping to the segment skip-list, and then often the caller of
VG_(mmap) would do another one for the same segment, just to change the SF_*
flags. Now VG_(mmap) gets passed the appropriate SF_* flags so it can do it
directly. This results in shorter, simpler code, and less work at runtime.
Also, strengthened checking in VG_(mmap), POST(mmap), POST(mmap2) -- now if the
result is not in the right place, it aborts rather than unmapping and
continuing. This is because if it's not in the right place, something has
gone badly wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2466
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
that when the client is killed by a coredumping signal, Valgrind will
generate the coredump itself, which is full of client state, rather than
Valgrind state; this core file will therefore be useful to the developer
in debugging their program.
The corefile generated is named vgcore.pidNNNNN (and maybe with .M on
the end in case of duplicates). If you set a logfile with --logfile,
then this name will be used as the basename for the core file, so that
both the core and the logs will be next to each other.
Valgrind respects the RLIMIT_CORE limit when generating the file; if the
limit is set to 0, then it will not generate one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2312
no longer exists. One advantage of this is that global
variables/structures needed for communicating between the two can be made
local. Also, the order in which things happen has been simplified.
This is mostly just a big refactoring. Startup is now a fair bit easier to
understand. Dependencies between the various startup stages are fairly well
documented in comments. Also, --help and --version now work properly --
eg. --help gives tool-specific help if --tool was specified. There is still
some parts where things could be reordered and/or simplified, and where the
dependencies aren't clear. These are marked with 'XXX'.
One new feature was added: ability to read options from ~/.valgrindrc and
./.valgrindrc. Part of this is support for specifying tool-specific options
in the form --toolname:tool-specific-option.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2222
code. Currently this is just for signal returns, but there's the start
of sysinfo/vsyscalls support, as used by the TLS libraries.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2150
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
with the aim of making it more robust, more correct and perhaps faster.
This patch removes the need to poll blocking syscalls, by adding a proxy
LWP for each application thread. This LWP is a kernel thread whose job
is to run all (potentially) blocking syscalls, and also to handle signals.
This allows the kernel to do more of the work of dealing with signals,
so on kernels which do this properly (2.6), Valgrind's behavious is a
lot more posix compliant. On base 2.4 kernels, we emulate some of the
missing 2.6 functionality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1918
Renamed:
VG_(read_procselfmaps_contents)() --> VG_(read_procselfmaps)()
VG_(read_procselfmaps)() --> VG_(parse_procselfmaps)()
VG_(read_symbols)() --> VG_(read_all_symbols)()
VG_(read_symtab_callback)() --> VG_(read_seg_symbols)()
Removed the Bool 'read_from_file' arg from (what is now)
VG_(parse_procselfmaps)(). If /proc/self/maps needs to be read beforehand, the
code calls (what is now) VG_(read_procselfmaps)() before. Still using the
static buffer which is not nice but good enough.
More importantly, I split up VG_(new_exe_segment)() into
VG_(new_exeseg_startup)() and VG_(new_exeseg_mmap)(). This is because at
startup, we were stupidly calling VG_(read_symbols)() for every exe seg, which
parses /proc/self/maps completely in order to load the debug info/symbols for
the exe seg (and any others we haven't already got the symbols for). Despite
the fact that the startup code reads /proc/self/maps to know which segments are
there at startup. In other words, we were reading /proc/self/maps several
times more often than necessary, and there were nested reads, which Stephan
Kulow's recent depth patch fixed (but in a pretty hacky way; this commit fixes
it properly). So VG_(new_exeseg_startup)() now doesn't cause /proc/self/maps
to be re-read. Unfortunately we do have to re-read /proc/self/maps for mmap(),
because we don't know the filename from the mmap() call (only the file
descriptor, which isn't enough).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1830
problem which caused the leak checker to misbehave following recent
PLT-bypass workaround.
In short, it is an error to announce to the skin, segments found which
belong to the low-level memory manager, because the skin may then mark
them as accessible to the client. This is wrong, and the client
should only acquire accessible memory via malloc etc and stack
movement. Now we carefully avoid mentioning any segment belonging to
the low level memory manager.
Take the opportunity to improve VG_(within_m_state_static) so that it
also detects pointers within the thread table. This can reduce the
number of blocks the leak checker spuriously thinks are still
reachable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1751
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
neatens other things up.
Also, it adds the --gen-suppressions option for automatically generating
suppressions for each error.
Note that it changes the core/skin interface:
SK_(dup_extra_and_update)() is replaced by SK_(update_extra)(), and
SK_(get_error_name)() and SK_(print_extra_suppression_info)() are added.
-----------------------------------------------------------------------------
details
-----------------------------------------------------------------------------
Removed ac_common.c -- it just #included another .c file; moved the
#include into ac_main.c.
Introduced "mac_" prefixes for files shared between Addrcheck and Memcheck,
to make it clearer which code is shared. Also using a "MAC_" prefix for
functions and variables and types that are shared. Addrcheck doesn't see
the "MC_" prefix at all.
Factored out almost-identical mc_describe_addr() and describe_addr()
(AddrCheck's version) into MAC_(describe_addr)().
Got rid of the "pp_ExeContext" closure passed to SK_(pp_SkinError)(), it
wasn't really necessary.
Introduced MAC_(pp_shared_SkinError)() for the error printing code shared by
Addrcheck and Memcheck. Fixed some bogus stuff in Addrcheck error messages
about "uninitialised bytes" (there because of an imperfect conversion from
Memcheck).
Moved the leak checker out of core (vg_memory.c), into mac_leakcheck.c.
- This meant the hacky way of recording Leak errors, which was different to
normal errors, could be changed to something better: introduced a
function VG_(unique_error)(), which unlike VG_(maybe_record_error)() just
prints the error (unless suppressed) but doesn't record it. Used for
leaks; a much better solution all round as it allowed me to remove a lot
of almost-identical code from leak handling (is_suppressible_leak(),
leaksupp_matches_callers()).
- As part of this, changed the horrible SK_(dup_extra_and_update) into the
slightly less horrible SK_(update_extra), which returns the size of the
`extra' part for the core to duplicate.
- Also renamed it from VG_(generic_detect_memory_leaks)() to
MAC_(do_detect_memory_leaks). In making the code nicer w.r.t suppressions
and error reporting, I tied it a bit more closely to Memcheck/Addrcheck,
and got rid of some of the args. It's not really "generic" any more, but
then it never really was. (This could be undone, but there doesn't seem
to be much point.)
STREQ and STREQN were #defined in several places, and in two different ways.
Made global macros VG_STREQ, VG_CLO_STREQ and VG_CLO_STREQN in vg_skin.h.
Added the --gen-suppressions code. This required adding the functions
SK_(get_error_name)() and SK_(print_extra_suppression_info)() for skins that
use the error handling need.
Added documentation for --gen-suppressions, and fixed some other minor document
problems.
Various other minor related changes too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1517
overview
-----------------------------------------------------------------------------
This commit introduces an optimisation that speeds up Memcheck by roughly
-3 -- 28%, and Addrcheck by 1 -- 36%, at least for the SPEC2000 benchmarks on
my 1400MHz Athlon.
Basic idea: that handling of A/V bit updates on %esp-adjustments was quite
sub-optimal -- for each "PUT ESP", a function was called that computed the
delta from the old and new ESPs, and then called a looping function to deal
with it.
Improvements:
1. most of the time, the delta can be seen from the code. So there's no need
to compute it.
2. when the delta is known, we can directly call a skin function to handle it.
3. we can specialise for certain common cases (eg. +/- 4, 8, 12, 16, 32),
including having unrolled loops for these.
This slightly bloats UCode because of setting up args for the call, and for
updating ESP in code (previously was done in the called C function). Eg. for
`date' the code expansion ratio goes from 14.2 --> 14.6. But it's much faster.
Note that skins don't have to use the specialised cases, they can just
define the ordinary case if they want; the specialised cases are only used
if present.
-----------------------------------------------------------------------------
details
-----------------------------------------------------------------------------
Removed addrcheck/ac_common.c, put its (minimal) contents in ac_main.c.
Updated the major interface version, because this change isn't binary
compatible with the old core/skin interface.
Removed the hooks {new,die}_mem_stack_aligned, replaced with the better
{new,die}_mem_stack_{4,8,12,16,32}. Still have the generic {die,new}_mem_stack
hooks. These are called directly from UCode, thanks to a new pass that occurs
between instrumentation and register allocation (but only if the skin uses
these stack-adjustment hooks). VG_(unknown_esp_update)() is called from UCode
for the generic case; it determines if it's a stack switch, and calls the
generic {new,die}_stack_mem hooks accordingly. This meant
synth_handle_esp_assignment() could be removed.
The new %esp-delta computation phase is in vg_translate.c.
In Memcheck and Addrcheck, added functions for updating the A and V bits of a
single aligned word and a single aligned doubleword. These are called from the
specialised functions new_mem_stack_4, etc. Could remove the one for the old
hooks new_mem_stack_aligned and die_mem_stack_aligned.
In mc_common.h, added a big macro containing the definitions of new_mem_stack_4
et al. It's ``instantiated'' separately by Memcheck and Addrcheck. The macro
is a bit klugey, but I did it that way because speed is vital for these
functions, so eg. a function pointer would have slowed things down.
Updated the built-in profiling events appropriately for the changes (removed
one old event, added a new one; finding their names is left as an exercise for
the reader).
Fixed memory event profiling in {Addr,Mem}check, which had rotted.
A few other minor things.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1510
interim. All hats off to Graydon Hoare for this, plus to whoever
devised the LD_ASSUME_KERNEL trapdoor.
This does not provide NPTL support. Instead it turns out we can ask
for the old LinuxThreads interface to be used (wonderful!)
Other than that we have to deal with kernels with SYSINFO pages at the
top of memory. No big deal, apparently.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1508
ASSUMED_EXE_BASE. This is now pointless, and causes problems for people
using Clearcase, since it seems their shared objects may not follow
the convention that they end in .so.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1458
asked-for feature.
A leak-check suppression looks like any other, and has the name 'Leak':
{
example-leak-suppression
Memcheck,Addrcheck:Leak
fun:malloc
fun:foo
fun:main
}
Fitting this into the core/skin split proved very tricky. Problem is
we want to scan the suppressions list to find Leak suppressions, but
- The core code can't do it because LeakSupp is a skin-specific
suppression kind.
- The skin code can't do it because most (all) of the types and
structures for the suppressions are private to the core.
Eventual "solution" (least-worst thing I could think of) is for the
skins using the leak checker to pass it the value of LeakSupp.
Even that isn't really clean because the skins consider it a value
of type MemCheckSuppKind but the core thinks it must be a
CoreSuppKind, and the two are not to be reconciled. So I kludged
around this by casting it to a UInt.
Nick, perhaps you know some way to smooth this out?
Apart from that all changes are straightforward.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1390
need to. Poking pages unnecessarily can cause a page fault which
under some rare circumstances can cause the kernel to extend the stack
segment all the way down to the poked page, which is seriously bad.
Fixes a bug shown by --trace-children=yes --skin=addrcheck
--leak-check=yes when running OpenOffice 1.0.1 on SuSE 8.1. This
distro seems to run with no stack limit, which is one prerequisite of
this bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1386
and Addrcheck. In coregrind/vg_memory.c, create
void VG_(generic_detect_memory_leaks
and remove several hundred lines of code from both ac_main.c and mc_main.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1250
non-readable, non-writable sections. Just ignore them. Comment in
the 1.0.X sources to the effect that this never happens is evidently a
lie.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1203
