Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292
gcc reports a warning:
m_stacktrace.c:183: warning: ‘xip_verified’ may be used uninitialized in this function
This warning is a false positive:
xip_verified is assigned in the following branch:
if (UNLIKELY(xip_verif >= CFUNWIND)) {
if (xip_verif == CFUNWIND) {
...
} else {
<<<< here xip_verified is initialised >>>>
}
}
xip_verified is then used only if xip_verif > CFUNWIND.
Assign a rubish value to xip_verified to silence gcc.
(??? there are GCC pragmas that can be used to
disable a warning only on a specific line e.g.
something like:
#pragma GCC diagnostic ignored "-Wuninitialized"
Addr xip_verified; // xip for which we have calculated fpverif_uregs
#pragma GCC diagnostic warning "-Wuninitialized"
instead of
Addr xip_verified = 0; // xip for which we have calculated fpverif_uregs
// 0 assigned to silence false positive -Wuninitialized warning
but the #pragma technique seems not used currently.
So, using the bypass by assigning a rubbish value
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13282
* other platforms (e.g. amd64) are first trying to unwind
with cfi info, then with the fp chain.
* fp unwind when code is compiled without frame pointer can
fail and give incomplete stack traces (often terminating
with a random program counter, causing a huge amount of
recorded stack traces).
This patch improves unwinding on x86 by:
* first time an IP is unwound, do the unwind both with
CFI technique and with fp technique.
If results are identical, IP is inserted in a cache of
'fp unwindable' IP
* following unwind of the same IP are then done directly
either with fp unwind or with cfi, depending on the
cached result of the check done during first unwind.
The cache is needed so as to avoid as much as possible cfi unwind,
as this is significantly slower than fp unwind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13280
In a big applications, some recursive algorithms have created
hundreds of thousands of stacktraces, taking a lot of memory.
Option --merge-recursive-frames=<number> tells Valgrind to
detect and merge (collapse) recursive calls when recording stack traces.
The value is changeable using the monitor command
'v.set merge-recursive-frames'.
Also, this provides a new client request: VALGRIND_MONITOR_COMMAND
allowing to execute a gdbsrv monitor command from the client
program.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13246
If VG_(use_CF_info) fails to find the next frame using loaded debug symbols, it
will still change the data in uregs. Thus, we need to have uregs_copy before
calling VG_(use_CF_info), and restore uregs if the call returns wrong data.
This fixes drd/tests/tc04_free_lock on MIPS.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12962
ARM by simply scanning up and looking for words that look like they
might be return addresses. Last-ditch hack for when the CFI trail
goes cold.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12641
__builtin_setjmp and __builtin_longjmp so that they can be selectively
replaced, on a platform by platform basis. Does not change any
functionality. Related to #259977.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11687
side components. (Florian Krohm <britzel@acm.org> and Christian
Borntraeger <borntraeger@de.ibm.com>). Fixes#243404.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11604
bogus, and produces essentially useless traces from them. With
gcc-4.4 and later, some valid thread stacks really are smaller than
this. Hence change the limit down to 256 bytes. Investigated by
Evgeniy Stepanov, eugeni.stepanov@gmail.com.
See bug 243270 comment 21.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11403
knows how to unwind. This is important when unwinding Thumb code
the CFA is often stated as being at some offset from r7.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11377
too. This is a first step towards making not be completely
x86/amd64-linux specific, and so replaces some x86/amd64-specific
stuff with more general constructions:
* structure 'DiCfSI', into which the info is summarised, has been
made target-specific (ugh), since the sets of registers to be
unwound differ on different targets.
* enum CfiReg and the CFIC_ constants have been expanded
accordingly, to handle both arm and x86/amd64 registers.
The abbreviation "IA" (Intel Architecture) has been used in a
few places where the x86 and amd64 definitions are shared.
* the CFI reader/summariser in readdwarf.c has been expanded &
generalised appropriately.
* the DiCfSI evaluator in debuginfo.c, VG_(use_CFI_info), has
also been generalised appropriately.
The main change is that instead of passing around triples
of (IP, SP, BP) values, a new structure 'D3UnwindRegs' is
passed around instead. This is defined differently for IA and
ARM and succeeds in hiding at least some of the differences
where we don't care about them.
Note also, D3UnwindRegs duplicates, in purpose and structure,
structure 'RegSummary' in priv_d3basics.h. This will be tidied
up in due course.
This commit almost certainly breaks stack unwinding on amd64-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10986
the changes to do with reading and using ELF and DWARF3 info.
This breaks all targets except amd64-linux and x86-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10982
frames other than the first one found.
This is taken from Jakub Jelinek's second patch on bug #210479.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10938
both wrapped up in XML tags (as before) but also in plain text in a
sequence of CDATA blocks. Normally only one, but in the worst case
the raw data will have ]]> in it, in which case it needs to be split
across two CDATA blocks.
This apparently simple change involved a lot of refactoring of the
suppression printing machinery:
* in the core-tool iface, change "print_extra_suppression_info" (which
prints any auxiliary info) to "get_extra_suppression_info", which
parks the text in a caller-supplied buffer. Adjust tools to match.
* VG_(apply_StackTrace): accept a void* argument, which is passed to
each invokation of the functional parameter (a poor man's closure
implementation).
* move PRINTF_CHECK into put_tool_basics.h, where it should have been
all along
* move private printf-into-an-XArray-of-character functions from
m_debuginfo into m_xarray, and make them public
* gen_suppression itself: use all the above changes. Basically we
always generate the plaintext version into an XArray. In text mode
that's just printed. In XML mode, we print the XMLery as before,
but the plaintext version is dumped into a CDATA block too.
* update the Protocol 4 specification to match all this.
This still isn't 100% right in the sense that the CDATA block data
needs to be split across multiple blocks if it should ever contain the
CDATA end mark "]]>". The Protocol 4 spec has this right even though
the implementation currently doesn't.
Fixes#191189.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10822
This commit tidies up and rationalises what could be called the
"messaging" system -- that part of V to do with presenting output to
the user. In particular it brings significant improvements to XML
output.
Changes are:
* XML and normal text output now have separate file descriptors,
which solves longstanding problems for XML consumers caused by
the XML output getting polluted by unexpected non-XML output.
* This also means that we no longer have to hardwire all manner
of output settings (verbosity, etc) when XML is requested.
* The XML output format has been revised, cleaned up, and made
more suitable for use by error detecting tools in general
(various Memcheck-specific features have been removed). XML
output is enabled for Ptrcheck and Helgrind, and Memcheck is
updated to the new format.
* One side effect is that the behaviour of VG_(message) has been
made to be consistent with printf: it no longer automatically
adds a newline at the end of the output. This means multiple
calls to it can be used to build up a single line message; or a
single call can write a multi-line message. The ==pid==
preamble is automatically inserted at each newline.
* VG_(message)(Vg_UserMsg, ..args..) now has the abbreviated form
VG_(UMSG)(..args..); ditto VG_(DMSG) for Vg_DebugMsg and
VG_(EMSG) for Vg_DebugExtraMsg. A couple of other useful
printf derivatives have been added to pub_tool_libcprint.h,
most particularly VG_(vcbprintf).
* There's a small change in the core-tool interface to do with
error handling: VG_(needs_tool_errors) has a new method
void (*before_pp_Error)(Error* err) which, if non-NULL, is
called just before void (*pp_Error)(Error* err). This is to
give tools the chance to look at errors before any part of them
is printed, so they can print any XML preamble they like.
* coregrind/m_errormgr.c has been overhauled and cleaned up, and
is a bit simpler and more commented. In particular pp_Error
and VG_(maybe_record_error) are significantly changed.
The diff is huge, but mostly very boring. Most of the changes
are of the form
- VG_(message)(Vg_UserMsg, "this is a message %d", n);
+ VG_(message)(Vg_UserMsg, "this is a message %d\n", n);
Unfortunately as a result of this, it touches a large number
of source files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10465
I tried using 'svn merge' to do the merge but it did a terrible job and
there were bazillions of conflicts. So instead I just took the diff between
the branch and trunk at r10155, applied the diff to the trunk, 'svn add'ed
the added files (no files needed to be 'svn remove'd) and committed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10156
- When printing suppressions, never print more entries than there are in the
stack. This avoids bogus suppressions in some cases! (I haven't seen
them on Linux, but I have seen them on Darwin.)
- When getting a stack trace, stop if we get an IP of zero or one; that
means we've hit the end of the stack. And don't include that entry in the
stack trace, because it's a guaranteed "???" if it's ever printed which is
useless.
- In VG_(apply_StackTrace), we can now rely entirely on the n_ip parameter
rather than looking for 0 or -1, because that check is done when the stack
trace is first obtained. In other words, stack traces all use an n_ip
parameter to record their size, whereas previously they used an odd
mixture of n_ip and null-termination.
- Rename 'n_ips' variables as 'max_n_ips' where appropriate; those left as
'n_ips' truly describe how many IPs there are in the stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9793
numbers) when Valgrind is running Wine. Modified version of a
patch by John Reiser (vgsvn+wine-load-pdb-debuginfo.patch) with
extensions to read a second format of line number tables.
Wine uses a new client request, VG_USERREQ__LOAD_PDB_DEBUGINFO,
to tell Valgrind when to read PDB info. Wine's implementation
of module loading is vastly different from that used by
ld-linux.so, and it is too difficult to recognize what is going
on just by observing the calls to mmap and mprotect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9580
- Now more clearly distinguishing between C++-demangling, Z-demangling, and
below-main renaming, particularly in 'get_sym_name'.
- --demangle=no no longer prevents Z-demangling, which makes more sense,
although it's unlikely to affect anyone.
- Broke the circular dependency between m_demangle and m_debuginfo by moving
below-main renaming into m_debuginfo.
- Renamed some get_fnname_* functions to make their effect clearer, and
improved their comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9138
'__libc_start_main', in Massif, m_debuginfo and m_stacktrace. As part of
this, --show-below-main is now visible to tools, and Massif pays attention
to it.
Improved the description of --show-below-main=yes in the manual.
Replaced some instances of "__libc_start_main" in the test *.exp files with
"(below main)", which is what will actually be seen. Also updated
scalar.stderr.exp*, which should make it get closer to actually passing.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9131
as denoting the logical end of the stack. This change stops printing
of a lot of junk below the logical "-1" end mark. See added comments
for details.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9051
stack unwind mechanism (the function VG_(record_ExeContext) et al),
clears up some associated kludges, and makes suppression matching work
more reliably.
Prior to this commit, a stack snapshot contained, at [0], the IP of
the relevant thread, and at all positions [1] and above, the return
addresses for the open calls.
When showing a snapshot to the user (in VG_(apply_StackTrace)), and
searching the stack for stack blocks (in VG_(get_data_description)), 1
is subtracted from positions [1] and above, so as to move these return
addresses back to the last byte of the calling instruction. This
subtraction is also done even in VG_(get_StackTrace_wrk) itself, in
order to make the stack unwinding work at all.
It turns out that suppression-vs-function-name matching requires the
same hack, and sometimes failed to match suppressions that should
match, because of this self-same problem.
So the commit changes the stack unwinder itself, so that entries [1]
and above point to the last byte of the call instruction, rather than
the return address. The associated kludges in VG_(apply_StackTrace)
and VG_(get_StackTrace_wrk) are removed, and suppression matching is
observed to work in a case where it failed before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8818
minor changes to make stack unwinding on amd64-linux approximately
twice as fast as it was before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8707
the new thread's stack, then make the stack unwinder use that information
to make a better guess at the stack bounds.
This helps avoid crashes trying to unwind the stack under wine when
the starting point is a routine without a proper stack frame.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7383
the --max-stackframe value. This makes it possible to run programs
with very large (primary) stack requirements simply by specifying
--max-stackframe.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7300
kludges^H^H^H^H^H^H^Henhancements:
r6802: For VG_(record_ExeContext) et al, add a new parameter
(first_ip_delta) which is added to the initial IP value before the
stack is unwound. A safe value to pass is zero, which causes the
existing behaviour to be unchanged. This is a kludge needed to work
around the incomplete amd64 stack unwind info in glibc-2.5's clone()
routine.
r7059: Add a last-ditch heuristic-hack to the amd64-linux stack
unwinder, which is used when all other methods fail. Seems like GDB
has something similar.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7118
