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
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
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
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
DARWIN branch. A big ugly DARWIN/trunk sync commit, mostly to do with
changing the representation of SysRes and vki_sigset_t. Functionality of
the trunk shouldn't be changed by it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9876
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
object file and use that information to decide which svma and bias
values to use when working out what section a symbol refers to.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9469
as they may be different to those for other sections of the ELF file
if we have separated debug information and the main file has been
prelinked since they were split. Fixes bug #185816.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9329
the ELF segment table into account when deciding on the mapping
between SVMA and AVMA for a section.
This also allows the BSS kludge to be dropped, as the BSS address is
now correctly determined.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9020
that are memory offsets) with PtrdiffT; OffT should only be used for file
sizes and offsets.
Change Off64T from a ULong to a Long, as it should be. Replace some uses
of ULong in the address space manager with Off64T to match.
Also add a comment explaining the meanings of the basic types like Addr,
OffT, SizeT, etc.
Also fix the prototype for VG_(pread) -- the last arg is an OffT, not an
Int.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8959
relatively minor extensions to m_debuginfo, a major overhaul of
m_debuginfo/readdwarf3.c to get its space usage under control, and
changes throughout the system to enable heap-use profiling.
The majority of the merged changes were committed into
branches/PTRCHECK as the following revs: 8591 8595 8598 8599 8601 and
8161.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8621
family of syscalls is impossible to write in a way that's portable and
correct. On some targets (eg x86-linux) you need to do sys_stat64 and
receive the results in a 'struct vki_stat64'. But on other targets
(eg amd64-linux) neither sys_stat64 nor 'struct vki_stat64' exist.
This commit adds a new type, 'struct vg_stat', which contains 64 bit
fields in all the right places, and makes VG_(stat) and VG_(fstat) use
it. This means callers to the two functions no longer need to worry
about the is-it-64-bit-clean-or-not question, since these routines
reformat the received data into a'struct vg_stat'. Kind of like what
glibc must have been doing for decades.
This (indirectly) fixes a bug on x86-linux, in which m_debuginfo would
sometimes fail to read debug info, due to VG_(di_notify_mmap) using
VG_(stat) (hence sys_stat) on the file, which failed, and when in fact
it should have used sys_stat64. Bug reported and tracked down by
Marc-Oliver Straub.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8522
support to Memcheck for tracking the origin of uninitialised values,
if you use the --track-origins=yes flag.
This currently causes some Memcheck regression tests to fail, because
they now print an extra line of advisory text in their output. This
will be fixed.
The core-tool interface is slightly changed. The version number for
the interface needs to be incremented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7982
the .text segment. Instead only reject ones that fall outside the r-x
area. This is in line with r7427, which instituted such a change in
other places in the system.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7546
interface and provides full power; and "OSetWord_", which is an
easier-to-use interface for if you just want to store words.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6841
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
mostly by a lot of comparison of this code vs that of
binutils-2.17/binutils/dwarf.c vs the relevant specs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6610
reading. Two sets of changes:
* New flags for debugging the readers.
--debug-dump=syms
--debug-dump=line
--debug-dump=frames
These (currently accepted but nonfunctional) are intended to
create output in the style of (that is, identical to)
/usr/bin/readelf --syms
/usr/bin/readelf --debug-dump=line
/usr/bin/readelf --debug-dump=frames
respectively. The plan is that flaws in these readers can then
be easily found by diff-ing the output against that from readelf.
Also, a new flag --trace-symtab-patt=<object filename pattern>
which is used to limit all debuginfo-related debug info to the
set of shared object names matching the given pattern. This
facilitates extracting the debuginfo details of one specific
shared object, which is usually what is required, rather than
having to wade through megabytes of junk from every object in
the process.
* Propagate the avma/svma/image address-naming scheme
(as described at the top of debuginfo.c) through large parts of
readelf.c and readdwarf.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6588
augmentation (has to do with read_encoded_Addr). This "fix" is a
kludge and may be replaced in future by something cleaner. See
extensive comment addition for the whole sorry tale.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6509
that hold various kinds of addresses during debuginfo reading, so as
to make it easier to understand. See comment at top of debuginfo.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6506
