(found by running regression tests with an outer memcheck).
(validated by running all regression tests "natively" on x86 and amd64,
and re-running regressions tests with outer memcheck).
==7500== 160 bytes in 2 blocks are definitely lost in loss record 75 of 246
==7500== at 0x2803CEF7: vgPlain_arena_malloc (m_mallocfree.c:1599)
==7500== by 0x280AAFA5: vgModuleLocal_dinfo_zalloc (misc.c:48)
==7500== by 0x2804E2A4: vgPlain_newXA (m_xarray.c:68)
==7500== by 0x280B3CD6: unitary_range_list (readdwarf3.c:703)
==7500== by 0x280B66CF: parse_var_DIE (readdwarf3.c:1631)
==7500== by 0x280BA0A6: read_DIE (readdwarf3.c:3248)
==7500== by 0x280BA170: read_DIE (readdwarf3.c:3269)
==7500== by 0x280BABC4: T.364 (readdwarf3.c:3611)
==7500== by 0x280BC634: vgModuleLocal_new_dwarf3_reader (readdwarf3.c:4035)
==7500== by 0x280609F4: vgModuleLocal_read_elf_debug_info (readelf.c:2529)
==7500== by 0x2805BD31: vgPlain_di_notify_mmap (debuginfo.c:610)
==7500== by 0x280362E3: valgrind_main (m_main.c:1944)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12419
__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
- "*(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
but with support for VLIW architectures with multiple opcodes per
instruction removed. Fixes#233595.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11106
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
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
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
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
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
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
that doesn't have a size, and DW_FORM_ref_addr (assuming my
interpretation of the standard is correct.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9058
its associated DIEs) occupies less space than stated in the CU's
header. icc9 appears to produce CUs with this anomaly. Not handling
the case causes the reader to lose sync at the start of the following
CU, since it hasn't skipped the junk bytes at the end of the current
CU, and it is basically hosed after that.
MERGE TO 3_4_BRANCH (?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9049
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
20081017 (experimental): accept DW_TAG_enumerator with only a
DW_AT_name but no DW_AT_const_value. This is in violation of the
Dwarf3 standard.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8700
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
try and reduce its space consumption. This change changes some long
linked lists into XArrays instead.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8540
variable & type reader dying on gcc-4.3.x produced Dwarf3. This is
done by handling DW_TAG_class_type and treating it the same as
DW_TAG_structure_type. I don't know if this is really correct or not.
This reader is still grossly inefficient in terms of space use, and
could be majorly improved, by storing information in arrays rather
than in linked lists with (sometimes) more than 5 million elements.
But this will have to wait.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8534
gcc-4.3 output. My reading of the DWARF3 standard is that a
DW_TAG_compilation_unit should have either DW_AT_ranges or a
(DW_AT_low_pc, DW_AT_high_pc) pair, but not both. So I think this is
a gcc bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8276
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
object (without D3 info) and a debuginfo (with D3 info), and then the
base object is prelinked to some nonzero address, but the debuginfo
object is left unchanged. A nasty and unprincipled hack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7590
