sizes up to a multiple of 8 (or whatever --alignment is). This is combined
with the "admin" bytes, resulting in the "extra" bytes. Added
VG_(malloc_usable_size) to the tool interface to support this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7133
interface:
r6805: Modify two thread-notification events in the core-tool
interface. This removes track_post_thread_create and
track_post_thread_join. The core can only see low level thread
creation and exiting, and has no idea about pthread-level concepts
like "pthread_create" and "pthread_join", so these are a bit
ambiguous.
Replace them with track_pre_thread_ll_create, which is notified before
a new thread makes any memory references, and
track_pre_thread_ll_exit, which is notified just before the new thread
exits, that is, after it has made its last memory reference.
r6823: Core-tool interface: give 'needs_tool_errors' an extra Boolean
indicating whether or not the core should print thread id's on error
messages.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7123
Split the scheduler initialisation into two phases, for reasons I
can't exactly remember. But I think it was so that the tool can be
told of the initial thread's TID before it is notified of any initial
address range permissions. Or something like that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7121
kludges^H^H^H^H^H^H^Henhancements:
r6802: For VG_(record_ExeContext) et al, add a new parameter
(first_ip_delta) which is added to the initial IP value before the
stack is unwound. A safe value to pass is zero, which causes the
existing behaviour to be unchanged. This is a kludge needed to work
around the incomplete amd64 stack unwind info in glibc-2.5's clone()
routine.
r7059: Add a last-ditch heuristic-hack to the amd64-linux stack
unwinder, which is used when all other methods fail. Seems like GDB
has something similar.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7118
interface and provides full power; and "OSetWord_", which is an
easier-to-use interface for if you just want to store words.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6841
the stack; instead use a stub in m_trampoline.S. This makes it
possible to deliver signals on non-executable stacks, and makes the
behaviour consistent with x86-linux and amd64-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6813
0x40 .. 0x43 instructions on Linux. Apparently these generate a
segfault and then restart the instruction.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6791
Another optimisation: allow tools to provide a final_tidy function
which they can use to mess with the final post-tree-built IR before it
is handed off to instruction selection.
In memcheck, use this to remove redundant calls to
MC_(helperc_value_check0_fail) et al. Gives a 6% reduction in code
size for Memcheck on x86 and a smaller (3% ?) speedup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6787
replacement for index/strchr in ld.so. Unfortunately the replacement
functionality was actually rindex/strrchr and amazingly it has taken
about 2.5 years for anyone to notice.
This fixes the x86-linux case; ppc32-linux and ppc64-linux fixes to
follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6783
Allow hashtables to dynamically resize (patch from Christoph
Bartoschek). Results in the following interface changes:
* HT_construct: no need to supply an initial table size.
Instead, supply a text string used to "name" the table, so
that debugging messages ("resizing the table") can say which
one they are resizing.
* Remove VG_(HT_get_node). This exposes the chain structure to
callers (via the next_ptr parameter), which is a problem since
callers could get some info about the chain structure which then
changes when the table is resized. Fortunately is not used.
* Remove VG_(HT_first_match) and VG_(HT_apply_to_all_nodes) as
they are unused.
* Make the iteration mechanism more paranoid, so any adding or
deleting of nodes part way through an iteration causes VG_(HT_next)
to assert.
* Fix the comment on VG_(HT_to_array) so it no longer speaks
specifically about MC's leak detector.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6778
exposes a performance problem with doing m_mallocfree.c sanity checks
(at --sanity-level=3, at least), caused by slowness in
listNo_to_pszB_min. This commit fixes the problem by caching the
results of queries to listNo_to_pszB_min.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6775
make VG_(arena_free) expensive if many superblocks have to be checked
before the right one is found. This change gives the arena a
dynamically expanding sorted array of superblocks, so that finding the
superblock containing an about-to-be-freed block (findSb) is now
O(log2 n) rather than linear in the number of superblocks in the
arena. Patch from Christoph Bartoschek.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6771
performance studies by Christoph Bartoschek:
* Increase the number of freelists per arena from 18 to 112, so as
to (drastically) cut down on the amount of freelist searching that
happens.
* Increase the size of the client and tool arenas, so as to reduce
the cost of finding arenas during freeing. This is a kludge; a
better solution would be to use binary search on superblocks, as
Christoph's patches do.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6770
reportable bugs.
AIX only: print name of missing syscall as well as number -- important
because there is no fixed name/number binding.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6765
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
and hence to segfaulting in vex on ppc32/64-linux in obscure
circumstances. VKI_MAX_PAGE_SIZE is 64k in recent Valgrinds.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6728
- 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
some attempt to discard existing translations first. Otherwise
Cachegrind (rightly) asserts on the basis that it is seeing duplicate
translation requests for the same entry point.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6698
Had to change XArray's comparison function to return an Int rather than a
Word so it's consistent with the rest of the world.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6680
Problem is that --help etc are handled by the tool exe. But a
ptrace-based launch scheme can't run "no program" if the user just
types "valgrind --help" because the launcher depends on starting the
client first and only then attaching valgrind to it using ptrace. So
instead provide a dummy do-nothing program to run when no program is
specified. m_main notices this and acts as if there really had been
no program specified.
This has no effect at all on Linux/ELF program launching.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6653
