represent the sizes of types, even on 32-bit hosts, where a type with
a size >= 2^32 is, well, if not meaningless, then at least impossible
to instantiate. This is of course motivated by reality .. on ppc32
SUSE11.0, the debuginfo for glibc-2.8 appears to contain a declaration
amounting to
char __EH_FRAME_BEGIN__ [4294967296]
Really.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8683
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
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
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
- Make sure that Valgrind does not complain when it tries to read the
debug information of a file of size zero when such a file is mmap()'ed
into memory.
- Make sure the filename is included in the error message that is
printed when reading the debug information fails for a file that is mmap()'ed
into memory.
- Fixed assertion failure that was triggered by supplying an output
buffer to VG_(seginfo_sect_kind)() that is smaller than the filename
to be copied into that buffer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8126
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
discarded if in fact we never got as far as reading anything into
DebugInfo. This unbreaks self-hosting.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7579
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
space manager for the name of the file it was mapped from as a fallback
solution.
This allows us to print the names of exe/dll files in the stack trace
when running programs under wine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7327
VG_(seginfo_sect_kind).") as it breaks DRD and possible Callgrind.
The segment kind identification code is basically broken for non-text
segments, but requires fixing at a higher level than this. See
discussion on valgrind-developers, 20 March 07, "Bug in
VG_(seginfo_sect_kind) ?"
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7267
and a 64-bit version of the same object (with the same name). Prior
to this, it would sometimes attempt to read debug info from the wrong
version of the object, complain that the magic number wasn't right,
and so end up reading nothing at all for that object.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7248
assert when a reference is made to a filename not in the filename
table. Fixes#150380 and #129937.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7191
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
Had to change XArray's comparison function to return an Int rather than a
Word so it's consistent with the rest of the world.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6680
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
abstraction implemented independently in several places in the code
base (bad!). This commit moves into public view a generic
implementation of it which has been lurking in readxcoff.c for some
time. Currently nothing uses it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6614
