add a simple compromise, in which the client can notify valgrind
that certain code address ranges are invalid and should be retranslated.
This is done using the VALGRIND_DISCARD_TRANSLATIONS macro in valgrind.h.
At the same time take the opportunity to close the potentially fatal
loophole that translations for executable segments were not being
discarded when those segments were munmapped. They are now.
Documentation updated.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@274
throw away the old signals simulation and more or less start again
from scratch. vg_signals.c is nearly a complete rewrite. In fact
this is now the third generation of the signals simulation.
The purpose of this is to properly support signals in threads -- a
nightmare combination. pthread_sigmask, pthread_kill and sigwait
are now alledged to work as POSIX requires.
In the process, throw away confusing and conceptually muddled old
implementation and replace with something which is more verbose but
conceptually cleaner, simpler and easier to argue is correct.
* When the client does sigaction/sigprocmask et al, the resulting
changes are stored verbatim in SCSS -- the Static Client Signal State.
So SCSS is the state the client believes the kernel is in.
* Every time SCSS changes, we recalculate the state the kernel
*should* be in so that our signal simulation works. This is the
SKSS -- Static Kernel Signal State. The kernel state is then
updated accordingly. By diffing the new and old SKSSs, the
number of real system calls made is minimised.
* The dynamic state of the client's signals is stored in DCSS
-- Dynamic Client Signal State. This just records which signals
are pending for which threads.
The big advantage of this scheme over the previous is that the SCSS ->
SKSS mapping is made explicit and gathered all in one place, rather
than spread out in a confusing way and done implicitly. That makes it
all lot easier to decide if the mapping, which is really the heart of
the signals simulation, is correct or not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@271
do things like "show functions covering 99% of all D2mr events *and* 99% of all
D2mw events" - before you could only choose the threshold for one.
Useful for me, but probably no-one else. Still mentioned it in the docs,
though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@269
have been ioctl(TCSETA)'d with a VTIMEout, we appear to need to ask if
the fd is writable, for some reason. Ask me not why. Since this is
strange and potentially troublesome we only do it if the user asks
specially, by specifying --wierd-hacks=ioctl-VTIME.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@264
startup, by looking for the ELF frame created on the process' stack
at startup. This avoids having to deal with problems caused by glibc
magic offsets.
WARNING: only works for 2.2 kernels right now. 2.4 is broken.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@258
will start up valgrind if it is not already running. This more or less
sidesteps the problem that sometimes valgrind.so isn't init'd first by
the dynamic linker.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@257
with the new vg_libpthread.vs linker script. Problem is that builds
where builddir != srcdir don't work now. Don't know how to fix.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@253
sysbols we need from libc are __umoddi3 and __udivdi3 ; other than that
valgrind.so is completely self-contained.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@244
- Don't waste a potentially huge amount of time calling describe_addr
on addresses in errors we aren't going to show.
- If an invalid address is just below %ESP, say that it might be due
to a gcc bug. Increase the window in which this is allowed to
1024 bytes below %ESP.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@229
assertions about the return value, rather than asserting the
non-NULL-ness of the function's address :) Classic beginner's mistake,
compounded by C's crappy (non-existent) type system, which allows me
to silently confuse Bool with Pointer-to-Function. What a great
programming language. Come back Haskell, all is forgiven.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@228
pops, as appear at function prologues/epilogues. Specifically, update %ESP
just once for the whole sequence. This reduces by about 20% the number
of calls to handle_esp_assignment (for kate in KDE 3.0, -O), which is a
good thing since that is quite expensive.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@227
- No longer aborting when encountering a N_SOL symbol after the 65535th
line in a file, just printing a warning/apology that annotations/messages
might be wrong.
This is a pain to fix properly, since it requires first guessing when a
line number overflow happens, then switching to one or more other files,
then switching back.
manual: wibble
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@225
Until now, valgrind waited for ld.so to call the .fini code in
valgrind.so, and took this as its cue to switch back to the real CPU
for the rest of the journey.
This is a problem if ld.so subsequently calls other .so's .fini code
and threading is in use, because they do pthread_* calls which cannot
be handled by valgrind's libpthread.so without valgrind actually being
active.
So we ignore the call to valgrind's .fini code, and run the program
all the way up to the point where it calls syscall exit() to
disappear. This makes the order in which the .fini sections are run
irrelevant, since Valgrind has control during all of them, and so
threading facilities are still available for all of them.
This change means Mozilla 1.0RC1 now exits a lot more cleanly than it
did.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@201
- Can now handle file sizes > 65536 lines, despite the stabs format only
storing line numbers in a short. Do this heuristically, by looking for
line number sequences that go from 65000-odd to 0-odd within the same
file.
This required changing the RiLoc.lineno field to 20 bytes, which gives a
maximum file length of 1,000,000-odd lines, whichs seems reasonable.
In order to keep RiLoc at 12 bytes (important because there are lots of
them) this required stealing four bits from the RiLoc.size field,
reducing it to 12 bits. This isn't too bad because the size is unlikely
to be larger than 4096 bytes -- we were already ignoring any ones larger
than 10,000 bytes because they were suspicious anyway (and see next
point).
- Tightened up the sanity checking on line address ranges. Previously any
range that looked suspicious (eg. > 10000 bytes, or not within the bound
of the segment info) was simply ignored(!) Now it prints a warning when
this happens and truncates the size to 1 to be safe; also there are some
extra assertions for totally space-cadet numbers.
(At first these checks were all assertions, but I tried a version of GNU
gas that produces a small handful of dodgy stabs entries; warnings
seemed a reasonable compromise.)
vg_cachesim.c:
- Removed the requirement that both types of cost centre (iCC, idCC) have
instr_addr as their second word. Less fragile -- now the only
requirement is that they both have their type tag as their first byte.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@197
This is needed to give reasonable behaviour for the insanity of a
Mozilla debug build, apparently even worse than the insanity of a
KDE 3 debug build. Change some limit calculations to use double
rather than int, so as to avoid overflows.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@193
