but with support for VLIW architectures with multiple opcodes per
instruction removed. Fixes#233595.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11106
any symbol in the r-x mapped segment to be a valid candidate. This
relaxes the filtering criterion slightly, makes it consistent with
other is-it-text? checks. Some addresses which before didn't get
mapped to anything are now correctly mapped to "vtable for Foo"
symbols.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11104
method of doing "strings file.dll | egrep '\.pdb|\.PDB'".
Distantly derived from a patch by leiz@ucla.edu. Fixes#222902,
although I still would prefer to do this the proper way, by parsing
the PE file properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11039
Wine as a notification to read PDB/PE debug info, contains a parameter
'reloc' whose purpose is unknown, and which is unused. Rename it
accordingly, to 'unknown_purpose__reloc'. (a non-functional change)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11036
minute older than the PE (the .exe/.dll it describes) even though this
doesn't seem particularly safe. Partially fixes#190675.
(patch from Dan Kegel)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11033
controlled from the command line. Recommended flags are
-v --trace-symtab=yes "--trace-symtab-patt=*nameofinteresting.exe"
Also print entry/exit information for DEBUG_SnarfCodeView and
DEBUG_SnarfLinetab.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11030
ARM which were originally in the loop but inadvertantly got lifted out
during recent merging. This appears to make stack unwinding work
again on ARM-Linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10988
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
dynbss and bss sections by merging them back together again.
This means that (a) we will find variables in the bss and (b) we won't
assert when there is a debuginfo file present where the bss is still
in one piece.
Patch from Jakub Jelinek, closes#217084.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10963
versions of gcc as shipped with Fedora 12. Specific changes include:
- Vastly increase the number of opcodes we understand how to
evaluate when processing a location expression.
- Process frame unwind data from the debug_frame ELF section as
well as the eh_frame section.
- Handle version 3 CIEs in frame unwind data.
- Handle the compact form of DW_AT_data_member_location which just
gives a constant offset from the start of it's base type instead
of a full location expression.
Based on patches from Jakub Jelinek on bugs #210479 and #210566.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10939
type STT_GNU_IFUNC which, instead of pointing directly at the
function, point at a routine which will return the address of
the real function. Redirection of indirect functions is handled
by valgrind as follows:
- When a redirection specification matches an indirect
function symbol an active redirection is added in the
normal way, but with the isIFunc flag set.
- When a call is made to an address which matches an
active redirection with the isIFunc flag set the call
is redirected, but not to the target address of the
redirection - instead it is sent to a small wrapper
routine that is preloaded into the client.
- The wrapper routine calls the original client routine
and collects the result, which it reports to valgrind
using a client request, and then returns the result to
the caller.
- When valgrind gets the client request it looks up the
active redirection for the indirect function and then
adds a new active redirection which redirects from the
address returned by the indirection function to the
redirection target. This new redirection does not have
the isIFunc flag set so behaves as a normal redirection.
In addition to the above we also add a few new redirections to
memcheck to capture internal calls made by glibc to things like
strlen, as these internal calls do not go through the indirect
function and instead go direct to the chosen implementation.
Based on a patch from Dodji Seketeli and comments from Jakub
Jelinek, this commit closes bug 206013.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10920
mapped rw-. Fixes#190820. Really, this logic is still pretty ropey; we
could do a lot better here.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10828
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
since gcc-4.4 on Fedora 11 will create DW_TAG_member entries within
it, and we need to have a plausible parent type on the stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10770
- Match the ordering of the non-tool-specific options in the usage message
with the order in the user manual. As a result, we now always print
--alignment and --trace-malloc in the core's usage messages, which saves
malloc-replacing tools from doing it themselves (and brings it in line
with options that only apply to error-collecting tools).
- Improved the presentation of the Vex options with --help-debug.
- Removed documentation of -d in the manual because it's a debugging-only flag.
- Documented --read-var-info in the manual. This fixes bug 201169.
- Renamed --auto-run-dsymutil as --dsymutil and documented it in the usage
message.
- Fixed an XML error in manual-core-adv.xml.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10703
const members in C++ code which are compile time constants that do no
exist in the class. They're not of any interest to us so we ignore them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10698
In addition to that it fixes a bug in restore_ctx handling, where it
was restoring the state from the same stack level in restore_ctx
context as is current in ctx, which is wrong, the CIE likely has no
DW_CFA_remember_state at all, while the FDE could have one.
(Jakub Jelinek). This is #200029, patch in comment #2.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10697
* VG_(find_seginfo): incrementally rearrange the DebugInfo list, like
most of the other list-searching functions do.
* rename all VG_(*seginfo*) functions exported from m_debuginfo to
VG_(*DebugInfo*). "seginfo" was a historical name which was mostly
but not completely, done away with some time back.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10678
that two overlapping symbols needs to be swapped. Fixes#163253.
Based on patch from John Reiser <jreiser@bitwagon.com>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10629
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
code section which is marked as uninitialised.
This can happen if you have incremental linking enabled in Visual
Studio, which causes a .textbss section to be added before the real
text section. We were picking up that .textbss section and using it to
compute the avma and bias for the code which was giving completely the
wrong results.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10394
following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364
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
of currently on-the-go register rules, rather than just one.
gcc doesn't appear to generate these (it's pretty darn obscure), but
they do turn up a piece of handwritten assembly somewhere in the
depths of Python-2.6 on amd64-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10075
