History log of /external/valgrind/coregrind/m_debuginfo/storage.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
112711afefcfcd43680c7c4aa8d38ef180e8811e 10-Apr-2015 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add a port to Linux/TileGx. Zhi-Gang Liu (zliu@tilera.com)
Valgrind aspects, to match vex r3124.

See bug 339778 - Linux/TileGx platform support to Valgrind



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
b6ba6d288e6000a8f95fba1dea671e0b53e26043 20-Mar-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Do not reuse Creg_IA_* for s390. Add dedicated entries Creg_S390_...


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15025 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
3cfee11b47be29060f52d52b56286b8d76371663 11-Mar-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Remove assertion. Unlikely as it may be, len may be huge
and therefore we cannot assert otherwise.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15001 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
9b54074df0311ae2509cda596b388b065d101b67 10-Mar-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Issue a warning if a function has more than 5 million bytes of
code. Previously functions exceeding that size were observed in the
field. Assert for 100x that amount.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14997 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
426e6a2ca4c94127fdbb0d0f9e89a831695f6cdb 20-Feb-2015 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> canonicaliseSymtab: fix silly logic that could cause the function to
loop forever. In particular, it will do that when two symbols have
exactly the same address range but differ in their .isText attribute.
Fixes #342117.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14948 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
205a42f1b48012de8b9633982d3a2d21cb26e006 17-Dec-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Comment change. Function vg_panic does not exist.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14816 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
3297124fa2116737066ac3cd709f18fdd5405163 23-Oct-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> 2 pints later: more coregrind constification.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14659 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
518850bf0da07ed3e2244e307268ae0fd80e93a8 23-Oct-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Constify coregrind.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14656 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
1ef70c6f00ab1b50d1936f77037e9923d8ed8c59 22-Oct-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Change VG_(allocEltDedupPA) to return a pointer to const. The reason is
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
8eebf23c35d97489c0d3c8b41dd542e00ae6acbd 18-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix a few casts that dropped type qualifiers. As pointed out by
-Wcast-qual.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14554 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
e2800c958044937e72eefa371c10ae47ac40e089 15-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> coregrind files shall use vg_assert not tl_assert.
Tool files shall use tl_assert not vg_assert.
Fix code accordingly.
Adapted check_headers_and_includes to make sure the code
stays clean in that respect.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14542 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
91ed8ccd3dae8a6abfaa45cc0d250df47b45187f 15-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Tidy up m_xarray.c.
VG_(newXA) and VG_(cloneXA) never return NULL. Remove pointless asserts.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14539 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
b49e4a5087d1927179baf1dea9dcc658fd778348 14-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Tidy up m_oset.c
- Document that the allocation function must ot return NULL.
- As a conequence of the previous requirement the various Create and AllocNode
functions cannot return NULL. Remove pointless asserts at call sites.
- Remove documentation of undefined function CreateWithCmp.
- Names of library functions (such as 'free') are reserved as a are names
beginning with underscores. Don't use those.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14531 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
4cace66777ca9ee73ea156210c04e9d4cc178395 13-Aug-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Reduce memory needed for symbols, by having the tocptr and local_ep
(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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
666ee9df4c2b6d801b199b8168208dbb46573c9d 09-Aug-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> This patch implements reading the directory information for source
files in the dwarf3 reader.
Basically, the change consists in replacing in the DiInlLoc struct
const HChar* filename; /* caller source filename */
by
UInt fndn_ix; /* index in di->fndnpool of caller source
dirname/filename */

A similar change is done in DiVariable struct, as the
read_filename_Table code is shared between the inline info reader
and the varinfo reader.
Note however that outputting dirname in variable description
is not done. Unclear if that is desired or not.
It should be trivially doable however.
Replacing filename by fndn_ix implies a bunch of semi-mechanical
changes.

The code to read the directory names is in the new function
static
XArray* read_dirname_xa (struct _DebugInfo* di, const HChar *compdir,
Cursor *c,
Bool td3 )

Note that readdwarf.c and readdwarf3.c have significant duplicated
logic. Would be nice to integrate these 2 dwarf readers in one
single reader. This function is directly inspired from
an equivalent piece of code in readdwarf.c.

Modified memcheck/tests/varinfo5.vgtest to test the dirname appears
in the inlined functions.


Impact on memory is neglectable (a few Kb on a big executable).



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14245 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
582d58245637ab05272d89fb94b12fd0f18fa0f8 08-Aug-2014 carll <carll@a5019735-40e9-0310-863c-91ae7b9d1cf9> This commit is for Bugzilla 334834. The Bugzilla contains patch 2 of 3
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334836.

POWER PC, add the functional Little Endian support, patch 2

The IBM POWER processor now supports both Big Endian and Little Endian.
The ABI for Little Endian also changes. Specifically, the function
descriptor is not used, the stack size changed, accessing the TOC
changed. Functions now have a local and a global entry point. Register
r2 contains the TOC for local calls and register r12 contains the TOC
for global calls. This patch makes the functional changes to the
Valgrind tool. The patch makes the changes needed for the
none/tests/ppc32 and none/tests/ppc64 Makefile.am. A number of the
ppc specific tests have Endian dependencies that are not fixed in
this patch. They are fixed in the next patch.

Per Julian's comments renamed coregrind/m_dispatch/dispatch-ppc64-linux.S
to coregrind/m_dispatch/dispatch-ppc64be-linux.S Created new file for LE
coregrind/m_dispatch/dispatch-ppc64le-linux.S. The same was done for
coregrind/m_syswrap/syscall-ppc-linux.S.

Signed-off-by: Carl Love <carll@us.ibm.com>

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14239 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
cae0cc22b83ffb260ee8379e92099c5a701944cb 08-Aug-2014 carll <carll@a5019735-40e9-0310-863c-91ae7b9d1cf9> This commit is for Bugzilla 334384. The Bugzilla contains patch 1 of 3
to add PPC64 LE support. The other two patches can be found in Bugzillas
334834 and 334836. The commit does not have a VEX commit associated with it.

POWER PC, add initial Little Endian support

The IBM POWER processor now supports both Big Endian and Little Endian.
This patch renames the #defines with the name ppc64 to ppc64be for the BE
specific code. This patch adds the Little Endian #define ppc64le to the

Additionally, a few functions are renamed to remove BE from the name if the
function is used by BE and LE. Functions that are BE specific have BE put
in the name.

The goals of this patch is to make sure #defines, function names and
variables consistently use PPC64/ppc64 if it refers to BE and LE,
PPC64BE/ppc64be if it is specific to BE, PPC64LE/ppc64le if it is LE
specific. The patch does not break the code for PPC64 Big Endian.

The test files memcheck/tests/atomic_incs.c, tests/power_insn_available.c
and tests/power_insn_available.c are also updated to the new #define
definition for PPC64 BE.

Signed-off-by: Carl Love <carll@us.ibm.com>


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14238 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
ade2eddf567a868bafad9110ed92acf7373a972b 31-Jul-2014 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for stack unwinding using the ARM32 specific EXIDX format.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14217 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
2386069c3a117630ebda167cef4ce747a1511eec 15-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> produce cfsi and str dedup pa at the same verbosity level


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14166 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
59e1f3c79e870a978d24add86db6d8c5450c8b63 14-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> This patch decreases significantly the memory needed to store the lineloc info.

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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
0b260824e9bea1fd6d2d6fabd4d112af124ecde6 05-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Replace copy/pasted loop of the "range search" by doing a -1 in the loop
for the "equal" case.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14133 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
05c459ea63c50a072cf1eb0868590e9c0b362f30 05-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Small fixes/improvements post-cfsi_m improvement
* Avoid printing the size of a null dedup pool
* Avoid warnings of 2 unused variables on some platforms


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14132 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
5c3dba227192de63d86f65ec7d9597c132818c37 05-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> This patch decreases significantly the memory needed to store the cfsi info.

On a big executable, the trunk needs:
dinfo: 155844608/106737664 max/curr mmap'd 155572624/102276760 max/curr

With the patch, we have:
dinfo: 134873088/70389760 max/curr mmap'd 134607808/66717512 max/curr

So, peak dinfo memory decreases by 21Mb, and final by 36Mb.

The memory decrease is obtained by:

* using a dedup pool to store the machine dependent part (cfsi_m)
of the cfsi information as this information is highly duplicated.
For x86 and arm64, the duplication factor of cfsi machine dependent
part is very high (up to a factor 60).
For arm64, it is more like a factor 3.
A 'variable size' (1, 2 or 4 bytes) is automatically used to identify
the cfsi_m, if there is less than or more than 255/64K different cfsi_m.

* not storing explicitely the length of a range for which a cfsi_m
is to be used: in a large majority of the cases, ranges are
consecutive, and so the end of a range is just one byte before
the start of the next range.
So, we do not store the length of the ranges.
If there is a hole between 2 ranges, the hole is stored explicitely
as a range in which we have no cfsi_m information.
On x86 and amd64, we have quite some holes (something like one hole
every 7 cfsi). On arm64, we have very few holes (less than one hole
every 50 cfsi).
Even with the nr of holes on x86/amd64, it is more memory efficient
to store the holes rather than to store the length of each cfsi.

* Merging consecutive ranges that have the same cfsi_m info:
Many cfsi are "mergeable": there is no hole between 2 cfsi, and their
machine dependent part is identical
(I guess the unwind info needed by valgrind is subset of the full
unwind info, and so, the cfsi entries are not merged by the compiler,
but can be merged for simple unwind). Depending on the platform
(x86, amd64, arm64) and of the library/object file, we can have a
significant nr of mergeable entries.


The patch is not very small, but a lot is mechanical changes.

The patch has been compiled and tested on x86/amd64/ppc32/ppc64
(but ppc does not use cfsi so that just verifies it compiles).
It has been compiled on arm64, and "tested" by launching valgrind on
one executable.
It has not been compiled on s390 and mips.
With some luck, maybe it will compile on these platforms.
And if that uses the whole provision of luck for 2014, it might even work
on these platforms :).
If it does not compile, the fix should be straightforward.
Runtime problems might be more tricky (but arm64 "worked out of the box"
once x86/amd64 were ok).

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@14129 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
0b9d0646949bd382758763664d3bf2d6115993ae 30-Jun-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Implement VG_(arena_realloc_shrink) similar to realloc, but can
only decrease the size of a block, does not change the address,
does not need to alloc another block and copy the memory,
and (if big enough) makes the excess memory available for other
allocations.

VG_(arena_realloc_shrink) is then used for debuginfo storage.c
(replacing an allocation + copy).
Also use it in the dedup pool, to recuperate the unused
memory of the last pool.
This also allows to re-increase the string pool size to the original
3.9.0 value of 64Kb. All this slightly decrease the peak and in use
memory of dinfo.

VG_(arena_realloc_shrink) will also be used to implement (in another patch)
a dedup pool which "numbers" the allocated elements.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14122 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
a0a73939b0398b6608fd6dbde49820ce6530d12c 15-Jun-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> This patch implements the support needed for stacktraces
showing inlined function calls.
See 278972 valgrind stacktraces and suppression do not handle inlined function call debuginfo

Reading the inlined dwarf call info is activated using the new clo
--read-inline-info=yes
Default is currently no but an objective is to optimise the performance
and memory in order to possibly set it on by default.
(see below discussion about performances).

Basically, the patch provides the following pieces:
1. Implement a new dwarf3 reader that reads the inlined call info
2. Some performance improvements done for this new parser, and
on some common code between the new parser and the var info parser.
3. Use the parsed inlined info to produce stacktrace showing inlined calls
4. Use the parsed inlined info in the suppression matching and suppression generation
5. and of course, some reg tests

1. new dwarf3 reader:
---------------------
Two options were possible: add the reading of the inlined info
in the current var info dwarf reader, or add a 2nd reader.
The 2nd approach was preferred, for the following reasons:
The var info reader is slow, memory hungry and quite complex.
Having a separate parsing phase for the inlined information
is simpler/faster when just reading the inlined info.
Possibly, a single parser would be faster when using both
--read-var-info=yes and --read-inline-info=yes.
However, var-info being extremely memory/cpu hungry, it is unlikely
to be used often, and having a separate parsing for inlined info
does in any case make not much difference.
(--read-var-info=yes is also now less interesting thanks to commit
r13991, which provides a fast and low memory "reasonable" location
for an address).

The inlined info parser reads the dwarf info to make calls
to priv_storage.h ML_(addInlInfo).

2. performance optimisations
----------------------------
* the abbrev cache has been improved in revision r14035.
* The new parser skips the non interesting DIEs
(the var-info parser has no logic to skip uninteresting DIEs).
* Some other minor perf optimisation here and there.
In total now, on a big executable, 15 seconds CPU are needed to
create the inlined info (on my slow x86 pentium).

With regards to memory, the dinfo arena:
with inlined info: 172281856/121085952 max/curr mmap'd
without : 157892608/106721280 max/curr mmap'd,
So, basically, inlined information costs about 15Mb of memory for
my big executable (compared to first version of the patch, this is
already using less memory, thanks to the strpool deduppoolalloc.
The needed memory can probably be decreased somewhat more.

3. produce better stack traces
------------------------------
VG_(describe_IP) has a new argument InlIPCursor *iipc which allows
to describe inlined function calls by doing repetitive calls
to describe_IP. See pub_tool_debuginfo.h for a description.

4. suppression generation and matching
--------------------------------------
* suppression generation now also uses an InlIPCursor *iipc
to generate a line for each inlined fn call.

* suppression matching: to allow suppression matching to
match one IP to several function calls in a suppression entry,
the 'inputCompleter' object (that allows to lazily generate
function or object names for a stacktrace when matching
an error with a suppression) has been generalised a little bit
more to also lazily generate the input sequence.
VG_(generic_match) has been updated so as to be more generic
with respect to the input completer : when providing an
input completer, VG_(generic_match) does not need anymore
to produce/compute any input itself : this is all delegated
to the input completer.

5. various regtests
-------------------
to test stack traces with inlined calls, and suppressions
of (some of) these errors using inlined fn calls matching.


Work still to do:
-----------------
* improve parsing performance
* improve the memory overhead.
* handling the directory name for files of the inlined function calls is not yet done.
(probably implies to refactor some code)
* see if m_errormgr.c *offsets arrays cannot be managed via xarray



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14036 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
7293d2530f8c60c1060f9f003e214cc341d35266 14-Jun-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> This patch adds a 'de-duplicating memory pool allocator':
include/pub_tool_deduppoolalloc.h
coregrind/pub_core_deduppoolalloc.h
coregrind/m_deduppoolalloc.c
and uses it (currently only) for the strings in m_debuginfo/storage.c
The idea is that such ddup pool allocator will also be used for other
highly duplicated information (e.g. the DiCFSI information), where
significant gains can also be achieved.
The dedup pool for strings also decreases significantly the memory
needed by the read inline information (patch still to be committed,
see bug 278972).

When testing with a big executable (tacot_process),
this reduces the size of the dinfo arena from
trunk: 158941184/109760512 max/curr mmap'd, 156775944/107882728 max/curr,
to
ddup: 157892608/106614784 max/curr mmap'd, 156362160/101414712 max/curr

(so 3Mb less mmap-ed once debug info is read, 1Mb less mmap-ed in peak,
6Mb less allocated once debug info is read).

This is all gained due to the string which changes from:
trunk: 17,434,704 in 266: di.storage.addStr.1
to
ddup: 10,966,608 in 750: di.storage.addStr.1
(6.5Mb less memory used by strings)
The gain in mmap-ed memory is smaller due to fragmentation.
Probably one could decrease the fragmentation by using bigger
size for the dedup pool, but then we would lose memory on the last
allocated pool (and for small libraries, we often do not use much
of a big pool block).
Solution might be to increase the pool size but have a "shrink_block"
operation. To be looked at in the future.

In terms of performance, startup of a big executable (on an old pentium)
is not influenced significantly (something like 0.1 seconds on 15 seconds
startup for a big executable, on a slow pentium).

The dedup pool uses a hash table. The hash function used currently
is the VG_(adler32) check sum. It is reported (and visible also here)
that this checksum is not a very good hash function (many collisions).

To have statistics about collisions, use --stats -v -v -v

As an example of the collisions, on the strings in debug info of memcheck tool on x86,
one obtain:
--4789-- dedupPA:di.storage.addStr.1 9983 allocs (8174 uniq) 11 pools (4820 bytes free in last pool)
--4789-- nr occurences of chains of len N, N-plicated keys, N-plicated elts
--4789-- N: 0 : nr chain 6975, nr keys 0, nr elts 0
--4789-- N: 1 : nr chain 3670, nr keys 6410, nr elts 8174
--4789-- N: 2 : nr chain 1070, nr keys 226, nr elts 0
--4789-- N: 3 : nr chain 304, nr keys 100, nr elts 0
--4789-- N: 4 : nr chain 104, nr keys 84, nr elts 0
--4789-- N: 5 : nr chain 72, nr keys 42, nr elts 0
--4789-- N: 6 : nr chain 44, nr keys 34, nr elts 0
--4789-- N: 7 : nr chain 18, nr keys 13, nr elts 0
--4789-- N: 8 : nr chain 17, nr keys 8, nr elts 0
--4789-- N: 9 : nr chain 4, nr keys 6, nr elts 0
--4789-- N:10 : nr chain 9, nr keys 4, nr elts 0
--4789-- N:11 : nr chain 1, nr keys 0, nr elts 0
--4789-- N:13 : nr chain 1, nr keys 1, nr elts 0
--4789-- total nr of unique chains: 12289, keys 6928, elts 8174
which shows that on 8174 different strings, we have only 6410 strings which have
a unique hash value. As other examples, N:13 line shows we have 13 strings
mapping to the same key. N:14 line shows we have 4 groups of 10 strings mapping to the
same key, etc.
So, adler32 is definitely a bad hash function.
Trials have been done with another hash function, giving a much lower
collision rate. So, a better (but still fast) hash function would probably
be beneficial. To be looked at ...




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14029 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
821283b2110420321fd3f60afcc799b287788c68 13-Jan-2014 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Initial implementation of CFI based stack unwinding for arm64-linux.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13774 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
f0c1250e324f6684757c6a15545366447ef1d64f 12-Jan-2014 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for ARMv8 AArch64 (the 64 bit ARM instruction set).


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13770 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
0f157ddb404bcde7815a1c5bf2d7e41c114f3d73 18-Oct-2013 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates (20XY-2012 ==> 20XY-2013)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13658 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
5d616dfbb8439dfd51a40ddf1dba970938baa1eb 02-Jul-2013 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge r13421:HEAD from branches/DISRV. This merges the debuginfo-server
stuff into the trunk.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13440 a5019735-40e9-0310-863c-91ae7b9d1cf9
4df0bfc0614379192c780c944415dc420d9cfe8e 28-Feb-2013 petarj <petarj@a5019735-40e9-0310-863c-91ae7b9d1cf9> mips: adding MIPS64LE support to Valgrind

Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.

More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
6bd9dc18c043927c1196caba20a327238a179c42 23-Nov-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Changes to allow compilation with -Wwrite-strings. That compiler option
is not used for testcases, just for valgrind proper.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13137 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
1636d33c13958b9c0e7d3059cdd5005746418eb2 15-Nov-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Char/HChar fixups for m_debuginfo and m_gdbserver.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13122 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
40628facff2285b0fce592381c6e26fdcd2a1252 21-Sep-2012 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Implement some extra DW_OPs - more constants and some unary operators.
Patch from Mark Wielaard on BZ#307038.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13010 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
f6716dd8f025c9ace67541f3360d7f4523496d8a 21-Sep-2012 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Rename CfiOp to CfiBinop in preparation for adding unary operators.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13009 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
c1d946eb075492d55397d0070349e3b8461bd793 24-Aug-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix up range checking in ML_(addLineInfo). Avoids assertion failure
reported in #304980. Based on a patch by Jiri Hruska (jirka@fud.cz).


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12891 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
03f8d3fc25f5a45c5826259d1b33b7f310117279 05-Aug-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates to include 2012.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12843 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
6f3f31879c615d53399fe82af7b5478cdb3dfb59 13-Jul-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix ppCfiReg for s390 so --trace-cfi=yes no longer asserts.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12741 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
54c45db2f978055aeca91aaccb05aac825523e6c 13-Jul-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Clean up the PDB reader somewhat, mostly in the area of biasing.
#296318 comment 9. (Jiri Hruska, jirka@fud.cz)



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12736 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
6b5625bb609b154766d2e138b61e15655f60b710 13-Jul-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Allow multiple rw and rx mappings in the ELF debuginfo reader.
Fixes #296318 (patch on comment 8). (Jiří Hruška, jirka@fud.cz)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12735 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
732b3583236d760c7c54cfe6d5ed5b957be96d9d 05-Jul-2012 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Allow an IFunc symbol to be merged with a non-IFunc symbol that
represents the underlying resolver function. Fixes BZ#301204.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12711 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
5db15403e889d4db339b342bc2a824ef0bfaa654 07-Jun-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge in a port for mips32-linux, by Petar Jovanovic and Dejan Jevtic,
mips-valgrind@rt-rk.com, Bug 270777.

Valgrind: changes to existing files.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12616 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
d483f8006a37e056d49c0fa131e5103848ce8312 06-May-2012 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Avoid duplicate primary names when merging identical symbol table entries.
--trace-redir=yes shows that there are duplicated redir entries e.g.
--32537-- TOPSPECS of soname NONE filename /home/philippe/valgrind/m_redir_trace/memcheck/vgpreload_memcheck-amd64-linux.so
--32537-- libc.so* strcasecmp_l R-> (2014.0) 0x04c28bf0
--32537-- libc.so* strcasecmp_l R-> (2014.0) 0x04c28bf0
--32537-- libc.so* __GI_strcasecmp_l R-> (2014.0) 0x04c28b70
--32537-- libc.so* __GI_strcasecmp_l R-> (2014.0) 0x04c28b70

These are caused by the merging of identical debug entries always
adding the two primary names, even if the entries are exactly the same.

This patch avoids duplicated names in debug info if the entry to merge
has only one name identical to the entry name to which we are merging.

This avoids the useless duplicated redir entries, and slightly decreases
the "dinfo" memory usage.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12554 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
ec062e8d96a361af9905b5447027819dfbfee01a 23-Oct-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update all copyright dates, from 20xy-2010 to 20xy-2011.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12206 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
7cf235b7622757d6a29b9a61d9698f7eda9d1ed1 21-Oct-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> ML_(ppSym): minor improvement in debug printing for DiSyms.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12185 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
796e4b25100561a9e953cfe4dad83130b0153ce5 26-Sep-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Re-enable the use of loctab (line number table) trimming, for a 5% to
10% reduction in debuginfo storage requirements for large applications
on 32 bit platforms. This code had been present since the MacOSX port
was merged but had been disabled. Remove equivalent code for
shrinking the symbol tables since they are much (4 x) smaller than the
line number tables, trimming them is hardly worth the effort.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12050 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
a5acac39bf3be7546222b1316faee5ee524be0d1 20-Sep-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> A refactoring change; no functional effect. struct _DebugInfo
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
a5cace0c2a3e212931badbf6398a0cd98393121a 15-Aug-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Remove the assumption, in m_debuginfo, that each address is associated
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
0b98239b3e0abd430dbc913454d63c7e3d8c8b12 05-Jul-2011 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Implement some extra DWARF ops that gcc 4.6.1 seems to use. Fixes #275284.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11856 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
6e9de463ef677f093e9f24f126e1b11c28cf59fd 28-Jun-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Delete the AIX5 port. The last release this worked for is 3.4.1,
and then only on AIX 5.2 and 5.3.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11842 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
b5b87408c0c99f9f6938d8cd921e2a5f420577c4 07-Mar-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add a port to IBM z/Architecture (s390x) running Linux -- Valgrind
side components. (Florian Krohm <britzel@acm.org> and Christian
Borntraeger <borntraeger@de.ibm.com>). Fixes #243404.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11604 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
fa5ce5616a17e79828fbc79f30b02b5085151e3c 24-Sep-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> On arm-linux, add r7 to the set of registers that the CFI unwinder
knows how to unwind. This is important when unwinding Thumb code
the CFA is often stated as being at some offset from r7.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11377 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
9eecbbb9a9cbbd30b903c09a9e04d8efc20bda33 03-May-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates to 2010.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11121 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
3026f71684a930286186aa10fef266c304672e8f 01-Jan-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Make the Dwarf3 CFI stack unwinding machinery work on arm-linux
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
67dda56288881c094a07aafd671e74b5a31f395b 16-Nov-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Handle the isIFunc flag when canonicalising the symbol table.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10943 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
3c9cf3442185b5891e15450d6e3058aeff6796fe 12-Nov-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Various improvements to DWARF handling to cope with changes in recent
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
94be74345b5245bc7c8451292779f096aa4ce69c 27-Jul-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Make sure the entire symbol is swapped when canonicaliseSymtab decides
that two overlapping symbols needs to be swapped. Fixes #163253.

Based on patch from John Reiser <jreiser@bitwagon.com>.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10629 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
738856f99eea33d86ce91dcb1d6cd5b151e307ca 15-Jul-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge coregrind/ changes from branches/MESSAGING_TIDYUP r10464.

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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
f76d27a697a7b0bf3b84490baf60623fc96a23af 28-May-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge the DARWIN branch onto the trunk.

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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
27a0024216fb483fb1d68b8dca116549c7e27385 29-Apr-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add some extra symbol comparisons, based on those from the DARWIN branch.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9677 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
c8259b85b701d25d72aabe9dc0a8154517f96913 23-Apr-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add support for reading Windows PDB debug info (symbols and line
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
4c245e595b9f6300d3120408ca873f7115d9cc7d 16-Mar-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix all the non-VEX problems identified with the Clang Static Analyzer.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9416 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
9f207460d70d38c46c9e81996a3dcdf90961c6db 10-Mar-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Updated copyright years.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9344 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
588658b13b5ad77672f323d48fe9da0ca60b0bcb 22-Jan-2009 tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> Don't assume that all global variables are in the data section - we
now cope with variables in the text, data, sdata and bss sections.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9021 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
10deba428bd24d2105dbbe5bf58469385cc740be 23-Dec-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> ML_(addDiCfSI)(): truncate DiCfSI's that fall partially but not
entirely inside the r-x mapped area, so that they fall entirely
within the mapped area. This is necessary in order to avoid
assertion failures later in check_CFSI_related_invariants().



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8877 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
f98e1c03ce4bea1fb092cdea5571c41f29f6df9b 25-Oct-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge Helgrind from branches/YARD into the trunk. Also includes some
minor changes to make stack unwinding on amd64-linux approximately
twice as fast as it was before.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8707 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
50fde23467d92281b32dd537d0d9a590263628c3 20-Oct-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Dwarf3 variable & type reader: use 64-bit numbers throughout to
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
9c606bd8634cd6b67bb41fa645b5c639668cfa2d 18-Sep-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge all remaining changes from branches/PTRCHECK. These are some
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
bee43c15c5aed57d25df177308347224aa461d9c 19-Aug-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Make VG_(addToXA) and VG_(addBytesToXA) 64-bit clean.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8525 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
a0b6b2cf9abc7b0d87be1215a245eaccc0452af9 07-Jul-2008 bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merged FORMATCHECK branch (r8368) to trunk.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8369 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
b8b79addf04dd5d0b558916e26df0b1927cbd758 03-Mar-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge in the DATASYMS branch.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7540 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
4d474d086188fd1f29fa97dbd84d8ea2e589a9b8 11-Feb-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates ("200X-2007" --> "200X-2008").


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7398 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
7888e2204fff6e7429236b4227ed16594e7743b9 28-Feb-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Handle DW_CFA_def_cfa_expression; also DW_OP_mul.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6627 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
72427fa91a5e05e3323b5a8a407bd8d7b04c75cc 27-Feb-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Add limited support for DWARF3 'expressions' in stack-unwind (CFI)
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
f767d967b9ef331dcd7d0cd4584f6570cd829333 12-Feb-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Essentially non-functional tidyings and improvements to debuginfo
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
50a3aa1c52eda3795abbb4a72da6840124a9d844 11-Jan-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> In struct _SegInfo, rename field 'size' to 'text_size' so as to be
consistent with all the other 'foo_start_avma'/'foo_size' pairings.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6508 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
c6d3f6f0aec8607dded979fd15a9876a486ec682 11-Jan-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Non-functional change: rename a bunch of variables and field names
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
9ebd6e0c607fa30301b1325874eb8de871c21cc5 08-Jan-2007 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6488 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
4ee4f98c6dd3dd9517954efc628753bf46811d2d 17-Oct-2006 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge r6129:

Changes to support XCOFF:

- allow modules to have 'member names' as well as file names. A member
name is a "foo.o" name inside a "bar.a"; necessary as AIX
keeps all its dynamic libraries in .a files.

- rename the type RiLoc to DiLoc (this holds a line number indication).
No idea why it was called RiLoc in the first place.

- trace changes in type SysRes

- implement VG_(di_aix5_notify_segchange)



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6266 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
2e54028ae63b2e4be7f737300a87d70f17b85edb 29-Aug-2006 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Slacken assertion slightly, and add comments. Fixes #133051
('cfsi->len > 0 && cfsi->len < 2000000' failed)



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6040 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c
eadcd86d1b0f59efed44c162ef4378ccfb528290 04-Apr-2006 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Cleanup/restructure m_debuginfo, as described in
coregrind/m_debuginfo/README.txt.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5823 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/storage.c