safer kernel interface to signalling a particular thread and it ensures
you can only send a signal to one of your own threads.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2795
been changed to return the ID of the thread group leader but which do not
have a gettid system call.
This breaks VG_(gettid) which assumes that the getpid system call will
give the thread ID if the gettid system call does not exist.
The (horrible) solution is to use readlink to see where /proc/self points
when the gettid system call fails.
BUG: 82114
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2771
changed to name the last byte in Valgrind's section, rather than one past the
last byte. This was because the last byte is 0xffffffff, and so one past gave
0x0, which screwed things up.
However, when this change was made, all the places where VG_(valgrind_end) is
used weren't adjusted appropriately. So this commit makes those adjustments.
It also renames the variable as VG_(valgrind_last), which makes the difference
between it and the other VG_(*_end) variables much clearer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2672
- removed various things that are no longer used
- made (module-)local some things that were global
- improved the formatting in places
Removed about 160 lines of code, and non-trivially reduced the number
of global entities.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2541
1. It simplifies various things a bit.
2. Valgrind/tools will run out of memory later than currently in many
circumstances. This is good news esp. for Calltree.
Some things were going in V's 128MB heap, and some were going in V's 128MB map
segment. Now all these things are going into a single 256MB map segment.
stage2 has been moved down to 0xb0000000, the start of the 256MB map segment.
The .so files needed by it are placed at 0xb1000000 (that's the map_base).
This required some bootstrapping at startup for memory -- we need to allocate
memory to create the segments skip-list which lets us allocate memory...
solution was to make the first superblock allocated a special static one.
That's pretty simple and enough to get things going.
Removed vg_glibc.c which wasn't doing anything anyway.
Removed VG_(brk) and associated stuff, made all the things that were calling it
call VG_(mmap)() instead.
Removed VG_(valgrind_mmap_end) which was no longer needed.
Rejigged the startup order a bit as necessary.
Moved an important comment from ume.c to vg_main.c where it should be.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2482
add a segment mapping to the segment skip-list, and then often the caller of
VG_(mmap) would do another one for the same segment, just to change the SF_*
flags. Now VG_(mmap) gets passed the appropriate SF_* flags so it can do it
directly. This results in shorter, simpler code, and less work at runtime.
Also, strengthened checking in VG_(mmap), POST(mmap), POST(mmap2) -- now if the
result is not in the right place, it aborts rather than unmapping and
continuing. This is because if it's not in the right place, something has
gone badly wrong.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2466
cause the stack to be marked as executable in order for them to work.
All assembler files have also had a declaration added so that the
object they generate will be marked as not needing an executable stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2446
the current reserved area, which effectively acts as a hard limit. The
setrlimit system call now simply updates the emulated limits as best
as possible - the hard limit is not allowed to move at all and just
returns EPERM if you try and change it.
This should stop reductions in the soft limit causing assertions when
valgrind tries to allocate descriptors from the reserved area.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2440
--logfile-fd --> --log-fd
--logfile --> --log-file
--logsocket --> --log-socket
to be consistent with each other and other options (esp. --input-fd). Also
renamed some related variables. The old names still work, for backwards
compatibility, but they're not documented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2429
The problem is that the use of VG_(system) causes a SIGCHLD to be sent
to the process, which ends up being delivered to one of the proxy LWPs
(which is a small problem in itself, but nothing too bad).
The proxy tells the scheduler LWP about this, and the scheduler LWP sends
a sigACK reply.
Then, while the proxy LWP is in the SigACK state, and the SigACK reply
is still queued in the message pipe, the scheduler LWP starts shutting
Valgrind down, and sends a SIGVGKILL to all proxy LWPs. This causes
the proxy to drop from sigACK state to WaitReq state, and it reads
further commands - one of which is the SigACK message - this causes the
assertion failure.
The fix is to simply make the proxy LWP exit immediately when it gets
a SIGVGKILL, and not process any more requests.
This change also fixes a bug in VG_(system), in which the child process
returns back into Valgrind rather than exiting when exec fails.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2284
segment to be moved up to stage2's brk segment. Instead, Valgrind's
use of brk is simulated with mmap. In order to prevent any unwanted use
of the process brk segment, it also sets the RLIMIT_DATA to 0, which will
make brk always fail. glibc's malloc will use mmap to allocate if brk
fails. We try to intercept glibc's brk, but malloc seems to always use the
library-internal version. (The client's use of brk has always been simulated,
and is unaffected by this change.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2266
Patch to provide a proper environment to the debugger
Although this patch isn't strictly needed to allow alternative debuggers to
be used, it is needed if you want to use an X based debugger such as ups
(and presumably ddd) as VG_(system) has until now passed an empty
enviroment when starting the debugger but that causes DISPLAY to be lost.
This patch causes VG_(system) to pass a copy of the client environment
instead, with the necessary mashing done to clean up the LD_xxx variables.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2233
- old CPUs (and their modern embedded clones) don't implement the TSC
- new machines with power management, the TSC changes rate, and so is
useless as a timebase
Valgrind doesn't use read_millisecond_timer very much these days, so
the expense of doing a gettimeofday syscall shouldn't be a huge issue.
Naturally, rdtsc is still available for client purposes (if the host CPU
supports it).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2226
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
If the proxyLWP for a thread got a signal just as we were sending the
syscall request to it, then we would end up running the syscall twice.
The fix is to not check the results pipe while sending the syscall request
- wait until we're in a better state for handling signals (the deadlock
the results-read was supposed to avoid cannot actually happen).
Related to that, if we're delivering a signal to a thread, and that thread
is currently waiting for a syscall to complete, make sure we collect the
syscall results before entering the signal handler (otherwise we may end
up bogusly trying to restart the syscall by moving EIP back, even though
it now points to the signal handler rather than the syscall instruction)
This change also adds an assertion to VG_(restart_syscall) to make sure
we were actually restarting a syscall and not just randomly changing EIP
(this found the problem above).
Also, make set/getitimer run in the proxyLWP context, so that they
modify/read the proxyLWP's timers rather than the schedluer LWP's timers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2013
- restart syscalls which return ERESETARTSYS
- make code to restart a syscall common
- keep a process-wide pending signal set to store as-yet
undelivered signals (only used in 2.4 mode; TODO: siginfo, queues)
- make execve work a bit better - it is impossible to recover from
execve failing, so we try to check that it will before running the
syscall itself (also fixes bug with SuSE 8.2 kernel)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1964
a logfile for that pid already exists. This may happen for programs
started during system boot which will tend to get the same pid each boot.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1928
with the aim of making it more robust, more correct and perhaps faster.
This patch removes the need to poll blocking syscalls, by adding a proxy
LWP for each application thread. This LWP is a kernel thread whose job
is to run all (potentially) blocking syscalls, and also to handle signals.
This allows the kernel to do more of the work of dealing with signals,
so on kernels which do this properly (2.6), Valgrind's behavious is a
lot more posix compliant. On base 2.4 kernels, we emulate some of the
missing 2.6 functionality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1918
number, will print it with commas delimiting it. Very useful when printing
large numbers.
Using it, was able to remove the wretched commify() function from Cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1869
with being called from SK_(pre_clo_init)(), before its startup code has been
run (just returns 0).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1868
