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
Fixed demangler bug -- it was relying on glibc for some functions. This
triggered an incredibly obscure bug in my experimental skin -- memcpy() was
called within the demangler at (about?) the same time as the dynamic linker was
fiddling with the memcpy() entry, which caused one word of memory (probably
some counter in the dynamic linker) to be incremented, which my skin didn't
like.
So I removed all (AFAICT) of the demangler's dependencies on glibc. This
required adding macros for memset, memcpy, strlen, strcmp..., to replace them
with their VG_(...) version. The only #includes now are to .h files that are
part of Valgrind.
Also required #defining "size_t" as "Int".
Also required adding VG_(memcmp)() to vg_mylibc.c.
Also removed the "-1 == EOF" part of the compile-time test in safe-ctype.h
that checks the character set is ASCII. This was to remove the dependency
on stdio.h. Slightly dodgy, but should be ok I think/hope.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1436
for a rwx mapping which contains the startup %esp.
Might be better to look for just rw-. Stack might not be executable
if there's a noexec patch, and x86-64 actually enforces the x bit
distinctly from r.
--> Look for just rw-.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1431
The veneers for msgrcv in vg_intercept.c and vg_libpthread.c are not
returning the number of bytes read correctly - they always return zero
for any non-error case, which causes programs using msgrcv to behave
somewhat non-optimally when running under valgrind ;-)
Attached is a patch against 1.9.3 which fixes this.
Tom
--
Tom Hughes (thh@cyberscience.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1424
for a rwx mapping which contains the startup %esp. This should be
more robust than the previous mechanism, which checked a small number
of known places and gave up if none matched. This change is motivated
by Gentoo Linux's high security mode, in which the stack location is
chosen randomly for each new process.
Thanks to Catherine Allen for helping out on this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1422
VG_(handle_esp_assignment)() was needed by a skin (and thus whether to register
it in the baseBlock) was different to that used when determining whether to
call it in code generation... so it could be (attempted to be) called having
not been registered.
Fixed this by consistifying the conditions, using a function
VG_(need_to_handle_esp_assignment)() that is used in both places. The bug
hadn't been found previously because no existing skin exercised the mismatched
conditions in conflicting ways.
Also took VG_(track).post_mem_write out of consideration because it's no longer
important (due to a change in how stack switching is detected).
----
Improved the error message for when a helper can't be found in the baseBlock --
now looks up the debug info to tell you the name of the not-found function.
----
Increased the number of noncompact helpers allowed from 8 to 24
----
Removed a magic number that was hardcoded all over the place, introducing
VG_MAX_REGS_USED for the size of the arrays needed by VG_(get_reg_usage)()
----
Also added these functions
VG_(get_archreg)()
VG_(get_thread_archreg)()
VG_(get_thread_shadow_archreg)()
VG_(set_thread_shadow_archreg)()
which can be useful for skins.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1419
100 bytes (added VG_DEFAULT_TRANS_SIZEB). Took the now-unnecessary settings
out of Nulgrind and CoreCheck. Also made .avg_translation_sizeB a UInt (from
an Int), to avoid possibility of negatives.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1413
VG_(get_shadow_archreg), VG_(set_shadow_archreg), VG_(shadow_archreg_address).
Curiously, the only way skins could previously access them was with
VG_(shadow_reg_offset), which wasn't very flexible.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1412
with similar functions, and made it visible to skins (useful).
Also bumped up the skin interface minor version number due to this change; this
bumping will cover any other binary-compatible changes between now and the next
release (after 1.9.3).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1410
occur... this is helpful when writing skins, because it's easy for problems
with SK_(instrument)() to screw it up.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1408
Also added declaration for VG_(get_error_where)() to vg_skin.h (which should
have been included with the last commit).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1407
- When recording errors, VG_(dup_extra_and_update)() previously was only
called if the 'extra' field was non-NULL. Now it's always called.
This is for two reasons:
a. The 'extra' field could be holding a non-pointer value that just
happens to be 0
b. The skin might want to update the error, even if it doesn't use
the 'extra' field.
A pretty minor change that shouldn't upset anybody.
- Made the ExeContext 'where' field of an error visible to skins, by
adding VG_(get_error_where)(). This can be useful, eg. for comparing
errors for equality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1406
easily be reached in ~12 hours flat out computation on a fast machine
with a simple skin. It happened to me.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1401
changes, print a message the first 3 times so the user at least knows
these requests are getting ignored. If I was less lazy I would make
these requests -- at least those pertaining to memory addressibility
-- be done properly. But I'm too lazy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1400
on their stacks and have those blocks automatically cleared when the
stack retreats past them. This never really worked, certainly didn't
work in a multithreaded setting, and slowed everything down due to
having to do even more stuff at %esp changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1399
These assumed that ROR sets the P and Z flags and in fact it
sets neither. Add an extra OR insn to really set those flags.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1397
As of now it is correct, following several hours study.
- Rename upd_cc parameters to simd_flags since that's what they
really mean: does this insn interact at all with %EFLAGS
(the simulated flags) ?
- Have a convention that calls to new_emit which specify
FlagsEmpty for both the def and use sets should pass False
as the simd_flags parameter; this seems more logical than
saying True. From partial evaluation of new_emit with
these args one can see it does nothing under such circumstances,
as one would hope.
- Add an alternative, unused implementation of new_emit in
which the state space is explicitly enumerated. Instructive.
--------------------------------------------------------------
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1396
(Int)False == (Int)FlagsEmpty, but still.
Whilst hunting (completely unsuccessfully) for some bug causing
MySQL to malfunction with some skins (memcheck), or with most
skins when --single-step=yes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1395
pthread_join to a cancelled thread not return PTHREAD_CANCELED as it
should. This was due to a mix up with stack offsets.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1392
