* better progress messages, to make it clear that reading of a
PDB is finished, and how much stuff was read from it
* don't mmap PDB files to read them -- instead use VG_(read).
This is because CIFS filesystem mounting only works reliably on
Linux when mounted with option '-o directio', and that
disallows mmap-ing files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11482
behave more like the original proposal in #245535. This makes it
more flexible and general. Also rename it.
* new name is --fullpath-after=
* allow multiple instances of --fullpath-after=
* don't require the specified strings to be prefixes, only substrings
But retain the elegant backwards-compatibility trick in Bart's r11312
commit: if --fullpath-after= is not specified at all, then behave
exactly as before.
Fixes#245535. A mixture of patches from Bart Van Assche
(bart.vanassche@gmail.com), Alexander Potapenko (glider@google.com),
and me (integration and documentation).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11430
- "*(int *)0 = " is apparently ignored by LLVM for who-knows-why
reason. Cast the zero to a volatile int * instead.
- remove an unused function that gcc failed to mention was unused
(why? because it was marked __attribute__((noreturn)) ?)
As an aside, clang/llvm-2.8 seemed to be able to successfully
compile Valgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11429
unbreaks the build breakage on Darwin introduced in r11397, which
was a fix for #234064. The breakage was subsequently reported
in #253420 and #253452, which this commit fixes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11406
read debuginfo from, use VKI_O_LARGEFILE, so as to ensure the open
succeeds for large files on 32-bit systems. Fixes#234064.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11397
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
code_alignment_factor, thereby assuming it is 1. This happens to be
OK on amd64-linux and s390x-linux because it really is 1, but on
arm-linux it is 2, and hence the boundaries between code-unwind areas
are simply wrong after any of DW_CFA_advance_loc{,1,2,4} are
processed. This patch provides the obvious fix.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11376
ignore it on the assumption that the .pdb is corrupt, rather than
running the system out of memory by trying to allocate a chunk of that
size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11226
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
