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
line with the DWARF3 spec and also with binutils/readelf.c:
- Update some comments
- Get rid of kludge_then_addDiCfSI; apparently no longer needed
- Pass the SegInfo's text_bias around in the AddressDecodingInfo,
so that ...
- read_encoded_Addr can set 'base' to the text_bias when handling
DW_EH_PE_absptr. This is the central change of this commit and
appears (to me) to be what DWARF3 requires. (The spec is less
than clear ..)
- don't use read_encoded_Addr to read the FDE arange field since
read_encoded_Addr's adding-on of a 'base' value is meaningless
here - the arange is not an address, but a value saying how many
bytes the FDE covers. Instead just read a little-endian value of
the right size. This is in accordance with DWARF3 and with
readelf.c. Add new function read_le_encoded_literal to make
this possible.
I believe this is all correct, and it's certainly much better than it
was. But given that the DWARF3 spec isn't as formal as it should be,
it's hard to be sure.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6611
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
Implement GNU binutils 'readelf' style output for --debug-dump=lines
(fully) and --debug-dump=frames (partially).
Initial testing with --debug-dump=lines shows our DWARF2 line number
reader behaves identically to readelf for all examples I tried so far.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6597
hex numbers: %x produces lowercase hex, and %X produces uppercase.
Unfortunately this probably changes the output in dozens of places.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6596
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
DW_CFA_set_loc, take into account any encoding info conveyed by the
augmentation string. See big comment in the code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6356
