* add a few more syscall wrappers, and fix a couple of buggy ones
* intercept strcmp et al in a few more libraries
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7249
and a 64-bit version of the same object (with the same name). Prior
to this, it would sometimes attempt to read debug info from the wrong
version of the object, complain that the magic number wasn't right,
and so end up reading nothing at all for that object.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7248
* Don't intercept putenv/getenv/setenv. Causes a lot of whinging
about missing TOC pointers.
* Add 'strcmp' to the bundle of 4 functions intercepted in all
objects.
* xlc now seems to route calls through to malloc_common, free_common,
calloc_common, realloc_common, memalign_common in libc. Intercept
those names too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7241
itself, if such exist. Attempt failed (or no such uses exist :-)
Commit does not change any code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7207
default be used. Fixes#151938. Unfortunately this makes the help
text non-constant, which could have a bad effect on regtesting; but
GDB is so usually installed in the standard place /usr/bin/gdb that I
don't think that's much of a big deal.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7192
assert when a reference is made to a filename not in the filename
table. Fixes#150380 and #129937.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7191
up passing uninitialised garbage on the stack to ptrace(SETREGS, ...)
for any fields in the struct which are not filled in. This does not
fix any known bugs, but seems like a good precautionary measure.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7187
attempt to fix debugger attach on ppc32-linux and ppc64-linux (see
#151908). The fork/ptrace-based mechanism works fine for x86-linux
and amd64-linux but not on ppc. I have no idea what is going on.
It seems like the forked child process (to which we will attach GDB)
does not stop when it does PTRACE_TRACE_ME and so things go downhill
very rapidly after that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7184
causes child processes after fork to fall completely silent, which can
make the output a lot less confusing. In addition it is pretty much
essential in XML output mode, so as to avoid mixing up any child XML
output with the parent's.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7177
suggested in #119404.
Prior to this commit, if the current traced process attempted to
execve a setuid executable, an error was always returned. The revised
behaviour is:
If the current (traced) process attempts to execve a setuid
executable:
* If --trace-children=yes is not in effect, the execve is allowed.
* If --trace-children=yes is in effect, the execve is disallowed
(as at present), but an error message is printed (unless in XML mode),
so at least the execve does not fail silently any more.
As per discussion on #119404 we could probably do a lot better, but
these changes are at least simple, useful and uncontroversial.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7175
says (essentially) "I am the replacement for function foo in object w/
soname bar.so". Now, if a redirection is mandatory, and bar.so is
loaded but foo is not found in its symbol table, then V aborts.
The initial motivation for this is making Memcheck work sanely on
glibc-2.6.X ppc32-linux. We really need to intercept 'strlen' in
ld.so right from startup. If ld.so does not have a visible 'strlen'
symbol, Memcheck generates an impossible number of errors resulting
from highly tuned strlen implementation in ld.so, and is completely
unusable -- the resulting undefinedness eventually seeps everywhere.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7165
the string converted wasn't entirely numeric. Using them for numeric
command-line options -- previously if you had a option "--foo=<n>", where
<n> is supposed to be an integer, then "--foo=blah" would be interpreted as
"--foo=0", because the "blah" would be converted to zero and the remaining
chars wouldn't be noticed.
Fixed an incorrect command-line option in two massif tests that this change
exposed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7149
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
