* produce (more) user messages when valgrind cannot read a pdb file.
* recover properly from an invalid/unsupported pdb file.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16465
This implements the interception of all globally public allocation
functions by default. It works by adding a flag to the spec to say the
interception only applies to global functions. Which is set for the
somalloc spec. The librarypath to match is set to "*" unless the user
overrides it. Then each DiSym keeps track of whether the symbol is local
or global. For a spec which has isGlobal set only isGlobal symbols will
match.
Note that because of padding to keep the addresses in DiSym aligned the
addition of the extra bool isGlobal doesn't actually grow the struct.
The comments explain how the struct could be made more compact on 32bit
systems, but this isn't as easy on 64bit systems. So I didn't try to do
that in this patch.
For ELF symbols keeping track of which are global is trivial. For pdb I
had to guess and made only the "Public" symbols global. I don't know
how/if macho keeps track of global symbols or not. For now I just mark
all of them local (which just means things work as previously on platforms
that use machos, no non-system symbols are matches by default for somalloc
unless the user explicitly tells which library name to match).
Included are two testcases for shared libraries (wrapmalloc) and staticly
linked (wrapmallocstatic) malloc/free overrides that depend on the new
default. One existing testcase (new_override) was adjusted to explicitly
not use the new somalloc default because it depends on a user defined
new implementation that has side-effects and should explicitly not be
intercepted.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15726
hardwired absolute path names. People can always arrange $PATH
such that these tools are found.
Fixes BZ #294065. Patch by Austin English <austinenglish@gmail.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15652
to help with MSVC2013 compiled code. Variant of a patch from
Mark Browning (mabrowningrr@gmail.com). Fixes#211529.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14942
output from /usr/bin/strings, so as to not get confused by substrings
".pdb" and ".PDB" when they don't appear at the end of a line.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14938
(a) the 2nd argument must not be NULL
This was true anyhow and requiring it allows us to simplify the function
by eliminating the local buffer.
(b) the memory pointed to by the 2nd argument is always initialised
In the past the output file name was not initialised in case VG_(open)
failed 10 times in a row. The call sites in m_main.c and m_gdbserver/target.c
were reading the uninitialised filename unconditionally. This was spotted
by IBM's BEAM checker.
Fix call sites, eliminate some magic constants along the way.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14706
that once an element has been allocated and added to the pool it must
not be modified afterwards. See the documentation in pub_tool_deduppoolalloc.h
The rest of the patch is ripple.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14654
(used for ppc64 platforms) #ifdef-ed and accessed by macros
that becomes NOP on non ppc64 platforms.
This decreases the debuginfo memory by about 2.5 Mb on a big 32 bit application.
Note : doing that, some questions were encountered in the way
tocptr and local_ep have (or do not have) to be copied/maintained
in storage.c canonicaliseSymtab
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14273
r14158 introduced a dedup pool to store pairs (filename,dirname).
The windows debug info reader (readpdb.c) performance was still to be
improved, as calls to ML_(addFnDn) were done for each line loc to add.
With this patch, the nr of calls to ML_(addFnDn) should be reduced
significantly.
Code has been compiled and regtested on linux, but no windows/wine test
was done.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14183
On a big executable, the trunk needs:
dinfo: 134873088/71438336 max/curr mmap'd, 134607808/66717872 max/curr
With the patch, we have:
dinfo: 99065856/56836096 max/curr mmap'd, 97883776/51663656 max/curr
So, peak dinfo memory decreases by about 36Mb, and final by 15Mb.
(for info, valgrind 3.9.0 uses
dinfo: 158941184/109666304 max/curr mmap'd, 156775944/107590656 max/curr
So, compared to 3.9.0, dinfo peak decreases by about 40%, and the final
memory is divided by more than 2).
The memory decrease is obtained by:
* using a dedup pool to store filename/dirname pair for the loctab source/line
information.
As typically, there is not a lot of such pairs, typically a UShort is
good enough to identify a fn/dn pair in a dedup pool.
To avoid losing memory due to alignment, the fndn indexes are stored
in a "parallel" array to the DiLoc loctab array, with entries having
1, or 2 or 4 bytes according to the nr of fn/dn pairs in the dedup pool.
See priv_storage.h comments for details.
(there was a extensible WordArray local implementation in readdwarf.c.
As with this change, we use an xarray, the local implementation was
removed).
* the memory needed for --read-inline-info is slightly decreased (-2Mb)
by removing the (unused) dirname from the DiInlLoc struct.
Handling dirname for inlined function caller implies to rework
the dwarf3 parser read_filename_table common to the var and inlinfo parser.
Waiting for this to be done, the dirname component is removed from DiInlLoc.
* the stabs reader (readstabs.c) is broken since 3.9.0.
For this change, the code has been updated to make it compile with the new
DiLoc/FnDn dedup pool. As the code is completely broken, a vg_assert(0)
has been put at the begin of the stabs reader.
* the pdb reader (readpdb.c) has been trivially updated and should still work.
It has not been tested (how do we test this ?).
A follow-up patch will be done to avoid doing too many calls to
ML_(addFnDn) : instead of having one call per ML_(addLineInfo), one
should have a single call done when reading the filename table.
This has also be tested in an outer/inner setup, to verify no
memory leak/bugs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14158
* Addition of a function to compute size of buffer needed for VG_(mkstemp)
* Use it to dimension buffers for all VG_(mkstemp) calls.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13409
contains a bunch of fields which are used as a very simple state
machine that observes mmap calls and decides when to read debuginfo
for the associated file. This change moves these fields into their
own structure, struct _DebugInfoFSM, for cleanness, so as to make it
clear they have a common purpose.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12041
with only one symbol. Instead, allow an address to have arbitrarily
many names. This reflects reality better, particularly for systemy
libraries such as glibc and ld.so, and is background work needed for
fixing #275284. This is not in itself a fix for #275284. A followup
commit to un-break compilation on OSX will follow shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11981
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
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
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
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
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
