Improve performance of dwarf3 reader using a hashtable of parsed abbreviations

For each DIE, the dwarf3 reader must know which data elements to read.
These elements are described by an abbreviation.
Re-reading these abbreviations for each DIE is costly as
the location of the needed abbreviation is found by scanning the full
abbv section, which is very costly.
(A small cache of 32 abbv offsets in the abbv section somewhat decreases
the cost, but reading the abbvs is still a hot spot, in particular for
big debug informations).

This patch:
  * adds an hash table of parsed abbreviations
  * all abbreviations for a CU are read in one single scan of the abbv
    section, when the CU header is read
So, with the patch, the di image is not accessed anymore for reading the abbvs
after the CU header parsing.

On a big executable, --read-var-info=yes user cpu changes from
  trunk:      320 seconds
to
  abbv cache: 270 seconds

This further improves on a previous (not committed) abbv cache that
was just caching up to 513 entries in the abbv pos cache and populating
the cache with an initial scan. The user cpu for this version was 285 seconds.

NB: this is some work in anticipation of a following patch that
will add reading dwarf3 inlined information, with the hope to make
this reading fast enough to activate it by default.

Note: on the examples I looked at, all abbreviations were numbered starting
from 1, with no holes. If that would always be the case, then one could use
an xarray of parsed abbreviations rather than an hash table. However,
I found nothing in the dwarf standard that guarantees that abbreviations
are numbered from 1. So, the hash table.
  




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14035 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
Announce in NEWS the support for inlined function calls in stacktraces/suppressions


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14037 a5019735-40e9-0310-863c-91ae7b9d1cf9
separate the tracing code in other function, call the tracing code only
if trace active.

This makes the code somewhat easier to read and somewhat more efficient



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14038 a5019735-40e9-0310-863c-91ae7b9d1cf9
Fix some obsolete comments, now that we have an ht of parsed abbvs


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14039 a5019735-40e9-0310-863c-91ae7b9d1cf9
When only reading inline info, no need to parse debug_types sections


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14040 a5019735-40e9-0310-863c-91ae7b9d1cf9
Add a comment to document a possible optimisation (avoid double reading
of DIEs when one or more parsers will read them also)
+ add the name of the parser in the barf output.
 


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14041 a5019735-40e9-0310-863c-91ae7b9d1cf9
Enable test cases for instructions implemented today.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14042 a5019735-40e9-0310-863c-91ae7b9d1cf9
Handle new IROp Iop_Abs64x2.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14043 a5019735-40e9-0310-863c-91ae7b9d1cf9