--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
- If no tool is specified, V now gives a short message and a list of
available tools. This was meant to happen previously, but a bug prevented
it from working properly; it gave the usage message instead.
- If a bad option is given, V now gives a short message rather than the full
--help. This make V consistent with all other programs I looked at.
- Now returning 0 when you do 'valgrind --help' and 'valgrind --version'
as other programs do.
- Removed VG_(startup_logging)() and VG_(shutdown_logging)() as they were
empty and have been for a long time (always?).
- Added various tests for these scenarios. Had to change the regtest
script slightly to allow for malformed command lines.
This addresses bug (wishlist) #82999.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2418
with 2.2 kernels and, it seems, on some systems with 2.4 kernels.
CCMAIL: 79179-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2384
forked process before using ptrace() to continue it, instead of asking
ptrace to deliver it, as that doesn't seem to work on some versions
of linux.
CCMAIL: 77824-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2380
supplied by the operating system for the code, data and stack segments.
Explicit references using these segments still won't work but they
will at least produce an assertion to indicate that they aren't
supported instead of raising a segmentation fault in the target
program because of an apparent privilege violation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2379
that when the client is killed by a coredumping signal, Valgrind will
generate the coredump itself, which is full of client state, rather than
Valgrind state; this core file will therefore be useful to the developer
in debugging their program.
The corefile generated is named vgcore.pidNNNNN (and maybe with .M on
the end in case of duplicates). If you set a logfile with --logfile,
then this name will be used as the basename for the core file, so that
both the core and the logs will be next to each other.
Valgrind respects the RLIMIT_CORE limit when generating the file; if the
limit is set to 0, then it will not generate one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2312
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
This patch adds translation tests for most of the basic x86 instructions and
fixes a few missing/broken instructions to work properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2242
Patch to allow debuggers other than GDB to be used
The patch replaces --gdb-attach and --gdb-path with --db-attach and
--db-command which are more general. The --db-command switch takes a
command string that can contain one or more instances of %p and %f markers.
The %p marker is replaced with the PID of the process to attach to and the
%f marker with the filename of the executable being attached to.
The default command is "gdb -nw %f %p" which gaves the same result as
currently.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2232
- 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
no longer exists. One advantage of this is that global
variables/structures needed for communicating between the two can be made
local. Also, the order in which things happen has been simplified.
This is mostly just a big refactoring. Startup is now a fair bit easier to
understand. Dependencies between the various startup stages are fairly well
documented in comments. Also, --help and --version now work properly --
eg. --help gives tool-specific help if --tool was specified. There is still
some parts where things could be reordered and/or simplified, and where the
dependencies aren't clear. These are marked with 'XXX'.
One new feature was added: ability to read options from ~/.valgrindrc and
./.valgrindrc. Part of this is support for specifying tool-specific options
in the form --toolname:tool-specific-option.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2222
capabilities, and uses it to see if it has SSE/SSE2/fxsave support before
trying to use fxsave at startup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2221
threads to have thread-private data which is quickly accessible via a
segment in the GDT, stored in %gs. The patch implements the relevent
syscalls (setthreadarea), and also manages switching the VCPU's segment
information at thread context-switch time. Mostly Tom Hughes' work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2215
to itself, Valgrind forks a child, and uses ptrace to manipulate its
state into what the client state would be at that point, and attaches
gdb to that. In addition to giving gdb clean state to inspect, it
also stops mistakes in gdb (eg, continuing) from killing your target.
It also makes gdb strictly read-only; any state changes made from within
gdb will not be reflected in the running client. Patch from Tom Hughes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2187
code. Currently this is just for signal returns, but there's the start
of sysinfo/vsyscalls support, as used by the TLS libraries.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2150
--branchpred=yes. I'm interested to know if these make a significant
difference for anyone - I see a small speed increase on the Pentium M.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2126
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
of testing for presence of NPTL by assuming that sys_futex is only
implemented when its a NPTL patched kernel.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2061
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2027
option --show-below-main is on. It's on by default. It also affects
suppressions generated with --gen-suppressions=yes. Updated reg tests
accordingly.
Also updated docs for this. And added some missing command-line args to docs.
Also compartmentalised the options a little in the docs, and rearranged the
order of options in the usage message, in anticipation of a bigger
rearrangement that will be necessary soon -- to distinguish options used by all
skins from those used by error-checking skins, to skin-specific ones.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2020
if the kernel has enough capabilities to run in 2.6 mode (ie, futex,
the right kind of clone, correct signal handling properties), and always
uses 2.4 mode. This will often not work on a 2.6 or RH9 2.4 kernel, but
it does help avoid a bug in the SuSE 8.2 (and possibly 9) kernels, which
look like they support enough to run in 2.6 mode, but get it wrong.
TODO: make the startup script/configure actually use this option.
Also some cleanup in printing debugging messages from vg_proxylwp.c, and
a small fix in the handling of ERESTARTSYS (assume that every syscall will
get interrupted from the outset, until it actually completes).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1965
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
Renamed:
VG_(read_procselfmaps_contents)() --> VG_(read_procselfmaps)()
VG_(read_procselfmaps)() --> VG_(parse_procselfmaps)()
VG_(read_symbols)() --> VG_(read_all_symbols)()
VG_(read_symtab_callback)() --> VG_(read_seg_symbols)()
Removed the Bool 'read_from_file' arg from (what is now)
VG_(parse_procselfmaps)(). If /proc/self/maps needs to be read beforehand, the
code calls (what is now) VG_(read_procselfmaps)() before. Still using the
static buffer which is not nice but good enough.
More importantly, I split up VG_(new_exe_segment)() into
VG_(new_exeseg_startup)() and VG_(new_exeseg_mmap)(). This is because at
startup, we were stupidly calling VG_(read_symbols)() for every exe seg, which
parses /proc/self/maps completely in order to load the debug info/symbols for
the exe seg (and any others we haven't already got the symbols for). Despite
the fact that the startup code reads /proc/self/maps to know which segments are
there at startup. In other words, we were reading /proc/self/maps several
times more often than necessary, and there were nested reads, which Stephan
Kulow's recent depth patch fixed (but in a pretty hacky way; this commit fixes
it properly). So VG_(new_exeseg_startup)() now doesn't cause /proc/self/maps
to be re-read. Unfortunately we do have to re-read /proc/self/maps for mmap(),
because we don't know the filename from the mmap() call (only the file
descriptor, which isn't enough).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1830
how stack snapshots are taken and printed; they can be used in preference
to VG_(get_ExeContext)() and VG_(pp_ExeContext)(). These are used by
Massif, my heap profiling skin.
Changed --num-callers to allow a backtrace size of 1.
Added code so that when Valgrind fails to disassemble an instruction, the
instructions line/file and address are printed out, which makes it easier to
work out where and what it is. Required the stack snapshot changes above.
MERGE TO STABLE?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1819
useful when trying to interpret users' problems. Each argv is printed on a
separate line, to make it extra clear where each one starts and ends.
MERGE TO STABLE (PLEASE!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1816
