Problem is that --help etc are handled by the tool exe. But a
ptrace-based launch scheme can't run "no program" if the user just
types "valgrind --help" because the launcher depends on starting the
client first and only then attaching valgrind to it using ptrace. So
instead provide a dummy do-nothing program to run when no program is
specified. m_main notices this and acts as if there really had been
no program specified.
This has no effect at all on Linux/ELF program launching.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6653
handling: why PRE(sys_sigreturn) has to construct a fake syscall
return value which, when written back to the guest state, leaves it
unchanged. It's only taken me about 3 years to realise why :-)
Fixes to ppc platforms to follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6650
allocated, rather than SizeT which is word-sized. Your average C++
lardware can easily turn over more than 4G in total in a half hour run
on a 32-bit machine, in which case the counter wraps around.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6649
(When generating 64-bit code, ensure that any addresses used in 4 or 8
byte loads or stores of the form reg+imm have the lowest 2 bits of imm
set to zero, so that they can safely be used in ld/ldu/lda/std/stdu
instructions.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6645
strings in 16-bit chunks, which can cause false errors in some cases
(sigh). So do the usual thing and replace it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6640
info (DW_CFA_def_cfa_expression, DW_CFA_expression,
DW_CFA_val_expression). Mechanism to support all of these is in place
although only DW_CFA_val_expression is currently connected up.
This is really nasty. The basic idea is to partially evaluate each
expression at the debuginfo-reading time by running it on a stack
machine in which each stack element is an expression tree. If the
expression can be 'run' successfully, the tree (dag, really) remaining
at the top of the stack is massaged and put into the DiCfSI record for
that address range. At unwind time the tree is evaluated if needed.
Such cases are in fact extremely rare and so the vast majority of
unwindings use the same mechanism as before.
As a result of all this:
* some obscure cases in glibc-2.5's libpthread.so unwind when they
didn't before
* --debug-dump=frames produces identical output to that of readelf
for libc-2.5.so and associated libpthread.so
* All the action centers around the new type CfiExpr, which is a
union expression-tree type in the same style as IRExpr et al
* Many dark corners of the CFI reader have been looked at and
(re-)validated
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6620
This introduces some macros to shorten the code for output of
strings to a file descriptor. I could use this a lot,
but this commit limits itself to the potential buffer overruns
(to ease backporting - provided we want to do this)
Heavy use of the macros probably blows up the code. Perhaps
it would be better to provide e.g. a VG_(write_str3) function
in the tool API.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6618
