Removed the SK_(written_shadow_regs_values)() function. Instead, skins that
use shadow regs can track the `post_regs_write_init' event, and set the shadow
regs from within it. This is much more flexible, since it allows each shadow
register to be set to a separate value if necessary. It also matches the new
shadow-reg-change events described below.
In the core, there were some places where the shadow regs were changed, and
skins had no way of knowing about it, which was a problem for some skins.
So I added a bunch of new events to notify skins about these:
post_reg_write_syscall_return
post_reg_write_deliver_signal
post_reg_write_pthread_return
post_reg_write_clientreq_return
post_reg_write_clientcall_return
Any skin that uses shadow regs should almost certainly track these events. The
post_reg_write_clientcall_return allows a skin to tailor the shadow reg of the
return value of a CLIENTCALL'd function appropriately; this is especially
useful when replacing malloc() et al.
Defined some macros that should be used *whenever the core changes the value of
a shadow register* :
SET_SYSCALL_RETVAL
SET_SIGNAL_EDX (maybe should be SET_SIGNAL_RETVAL? ... not sure)
SET_SIGNAL_ESP
SET_CLREQ_RETVAL
SET_CLCALL_RETVAL
SET_PTHREQ_ESP
SET_PTHREQ_RETVAL
These replace all the old SET_EAX and SET_EDX macros, and are added in a few
places where the shadow-reg update was missing.
Added shadow registers to the machine state saved/restored when signal handlers
are pushed/popped (they were missing).
Added skin-callable functions VG_(set_return_from_syscall_shadow)() and
VG_(get_exit_status_shadow)() which are useful and abstract away from which
registers the results are in.
Also, poll() changes %ebx (it's first argument) sometimes, I don't know why.
So we notify skins about that too (with the `post_reg_write_syscall_return'
event, which isn't ideal I guess...)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1642
(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
- getcwd() now uses the result for the post_mem_write length rather than
the argument, which would have over-estimated
- accept(), recvfrom() and getsockopt() can now all take NULL buffers (which
are quite legitimate) without Memcheck giving spurious errors
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1579
to assume that all sockaddrs are non-NULL and non-zero in
length. This isn't always true, and when I ran a program that
used a NULL sockaddr through Valgrind it segfaulted. I believe
that the change that I made fixes this bug in general, but I
might be overlooking something.
From kclark@CetaceanNetworks.com (Kevin D. Clark)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1440
14-hg-mmap-magic-virgin
This does two things:
1. change the signatures of the new_mem_mmap and change_mem_mprotect
functions to remove the pointless 'nn' argument. This makes them match
the signature of new_mem_startup...
2. change helgrind to mark memory created by mmap as if it were the
same as other magically pre-inited memory. Implement this by pointing
helgrind's new_mem_mmap function at new_mem_startup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1263
20-hg-secmap
HELGRIND: fix bugs causing a torrent of "access to distingished map"
messages. There were two: one is some absurdly broken rounding/padding
code in set_address_range_state() (how did anything work!?). The other
was some odd looking code in the tracking of attaching shared memory
segments. Since they're semantically very similar to mmap, track them
as such.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1257
valgrind.in 1.17.2.3
vg_syscall_mem.c 1.58.2.12
Add Jeremy Fitzhardinge's --weird-hacks=lax-ioctls patch, and add some docs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1244
vg_syscall_mem.c 1.58.2.8 and 1.58.2.10
vg_unsafe.h 1.8.4.2
Support for __NR_ptrace, thanks to Jason Molenda. Now valgrind can be
used to debug GDB. Bwaha!
Kludge to work around the problem that the /usr/include/sys/user.h on
R H 6.2 doesn't define struct user_fpxregs_struct (problem appeared
with Jason Molenda's ptrace patch).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1192
from core error ones:
- Split up VG_(panic) into VG_(core_panic) and VG_(skin_panic)
- Likewise, split vg_assert into vg_assert and sk_assert
- Added a new need string: `bug_reports_to'
- Removed VG_(skin_error) which was a previous wussy attempt at this change.
This removed the need for the hacky redeclaration of VG_(skin_error) in
vg_profile.c, which is good.
At the moment, Julian and Nick's email addresses are hard-coded into each skin
individually, rather than using a #define in vg_skin.h, because that didn't
feel quite right to me... jseward@acm.org is still done with a #define for
core errors, though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1164
LDTs and __NR_modify_ldt.
- Each thread has its own LDT. Usually NULL, but if we need to
change an entry, it is allocated. LDTs are inherited from parents
as one would expect.
- We intercept __NR_modify_ldt and update the calling thread's LDT
accordingly. This is done in coregrind/vg_ldt.c. The kernel
never sees these syscalls.
- New architectural state for %cs, %ss, %ds, %es, %fs and %gs.
Probably overkill including %cs and %ss. These are saved and
restored in the usual way, _except_ at syscalls -- there's no
point, since we are hiding all LDT operations from the kernel now.
This does assume that no syscall implicitly looks at the
segment registers, but I think that's safe.
Still only halfway there. JITter is still unaware of seg regs
and override prefixes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1133
