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
Slightly refined the NEWS entry for silly/fishy args


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14159 a5019735-40e9-0310-863c-91ae7b9d1cf9
Small fixes in 'getting started' section of user manual

* Mention --read-inline-info=yes as an alternative to compile without inlining.

* Mention that stabs debuginfo reader is not working anymore since 3.9.0



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14160 a5019735-40e9-0310-863c-91ae7b9d1cf9
add test cases for "LD1/ST1 (multiple 1-elem structs to/from 2 regs,
post index)" (16b only)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14162 a5019735-40e9-0310-863c-91ae7b9d1cf9
Bug 337094 ifunc wrapper is broken on ppc64.

ppc64 uses function descriptors, so we need to get the actual function
entry address for the VG_USERREQ__ADD_IFUNC_TARGET client request, but
we need to return the function descriptor itself from the ifunc_wrapper.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14163 a5019735-40e9-0310-863c-91ae7b9d1cf9
arm64: get_Dwarf_Reg: at least handle the case of requesting XSP
instead of failing.  This makes some of the memcheck/tests/varinfo*
tests work somewhat correctly on arm64-linux.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14164 a5019735-40e9-0310-863c-91ae7b9d1cf9
Bug 336619 valgrind --read-var-info=yes doesn't handle DW_TAG_restrict_type.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14165 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