| ede7291ec0a6035a30a97b22620f9bc6c971bd85 |
|
25-Aug-2015 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix a leak of the abbrev hash table when --read-var-info=yes is given
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15590 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| b3a1e4bffbdbbf38304f216af405009868f43628 |
|
21-Aug-2015 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update copyright dates, to include 2015. No functional change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15577 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| c6e5d76e9eea8625f385ff844545c688c91938da |
|
06-Aug-2015 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix printf format inconsistencies as pointed out by gcc -Wformat-signedness.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15500 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 8eb8bab992e3998c33770b0cdb16059a8b918a06 |
|
21-Jul-2015 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bug 345248 - add support for Solaris OS in valgrind
Authors of this port:
Petr Pavlu setup@dagobah.cz
Ivo Raisr ivosh@ivosh.net
Theo Schlossnagle theo@omniti.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15426 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| ad4e979f408239dabbaae955d8ffcb84a51a5c85 |
|
05-Jul-2015 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix typos in source code. Patch by Dmitriy (olshevskiy87@bk.ru).
Fixes BZ #349874
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15394 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| ebb889307951acf917213ba93e2b6f02801d1647 |
|
09-Feb-2015 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bug #343978 Recognize DWARF5/GCC5 DW_LANG_Fortran 2003 and 2008 constants.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14923 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| c505820a8b10066dcbdcc7ab36b8ae55bd671575 |
|
17-Dec-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove two fixed-size buffers in the dwarf readers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14820 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 866862a87a06a70e2e0c0d7e5c773e252db8ecdd |
|
13-Dec-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix BZ #116002.
Left justification of strings in myvprintf_str was mixed up.
Now fixed and %s formats changed accordingly.
In function myvprintf_int64: the local buffer was not large
enough to hold ULONG_MAX in binary notation. Numbers were
truncated at 39 digits.
Testcases added.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14808 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 611fd68095bd837171574815cceb2225ed2aeb9d |
|
07-Dec-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove fixed size arrays in the dwarf-3 parser.
Use proper initialisation functions for the type and variable parser.
Add functions to release the dynamically allocated functions.
No longer maintain content of popped-off stack entries as that is
essentially freed memory and complicates matters unnecessarily.
Part of fixing BZ #337869.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14801 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| b527a5b139b310d593c5ad7c0a1ceaf58249f5e1 |
|
26-Nov-2014 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bug 341238. Recognize GCC5/DWARFv5 DW_LANG constants Go, C11, C++11, C++14.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14791 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 8167a03ce124625e2f950e89e7b6cf7e69e6945a |
|
19-Nov-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix typos in a comment
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14737 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.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/readdwarf3.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/readdwarf3.c
|
| 09a4c794458cdb9dea743fa40e450150a2725257 |
|
18-Oct-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Change the definition of VgHashTable to not have pointer type.
This is (a) consistent with how the other containers are defined
and, more importantly, (b) allows the constification of the hash table API.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14639 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| bb861b524aabbe064269ddb78fa32dc682dd7657 |
|
07-Oct-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
follow up to fix for 339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...
The fix committed in revision 14603 is properly fixing the bug 339721.
However, when enabling the dwarf tracing, the DW_FORM_ref_sig8 causes
a segmentation violation, as the tracing code is shared with the
reading code. But the DW_FORM_ref_sig8 reading code is dereferencing
some data structure that is only initialised when --read-var-info=yes.
So, in case DW_FORM_ref_sig8 form reading is done and --read-var-info=no,
then check that we are tracing, and avoid dereferencing the (not initialised)
signature hash table.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14610 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| d4636ab82334c239c311b296cba66cc559048e36 |
|
06-Oct-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
fix 339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...
The skip code was wrongly skipping 16 bytes, while only 8 are read
for a DW_FORM_ref_sig8.
Note that the problem is made visible by an assert when using
--trace-symtab=yes but in fact this is a real bug in the dwarf reader,
that was introduced in one of the optimisations done for the inline info.
It can manifest itself with other symptoms:
One of the 2 following assertions can fail:
vg_assert (check_sibling == sibling);
vg_assert (get_position_of_Cursor (&check_skip)
== get_position_of_Cursor (&c));
Or the following error can be given:
--29973-- WARNING: Serious error when reading debug info
--29973-- When reading debug info from /home/philippe/valgrind/trunk_untouched/memcheck/tests/dw4:
--29973-- Overrun whilst reading .debug_info section
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14603 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.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/readdwarf3.c
|
| bf0ea23aef2a2a1c5aac02ada367ca6f983cbcb7 |
|
14-Sep-2014 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
ML_(dinfo_zalloc/strdup) never return NULL. Remove pointless
asserts at call sites.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14534 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| ba60227fa4fb14672c0e5e91486b25234fb1beca |
|
08-Sep-2014 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bug 338803 followup. Only print cross-CU warning when -v is given.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14492 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 6ae06edfc65c35528efd5459572349f5b918efd5 |
|
06-Sep-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Partial bypass for 338803 Handling of dwz debug alt files or cross-CU is broken
This patch avoids dereferencing absori that are in other CUs than
the CU currently being read.
This avoids dwarf reading errors when reading inlined information.
The bypass results in inlined function being reported as
UnknownInlinedFun rather than the real correct function name.
--read-var-info=yes is still broken for unknown reasons
(probably type reading is doing some other cross-CU references ?).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14476 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 3e49e4c2cb9a4394fd12780618e50d19d3c3a404 |
|
03-Sep-2014 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
readdwarf3.c: Improve error message on bad DW_FORM_GNU_[ref|strp]_alt usage.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14444 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| 8b662d50e99428ea6b76d44a80ffaaf73eb51584 |
|
05-Aug-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
fix 338024 inlined functions are not shown if DW_AT_ranges is used
Based on investigation and patch by Matthias Schwarzott.
(no small test found that reproduced the problem,
but the equivalent patch given in bug 338024 fixed the inlined stack
trace in a big shared lib).
Would be nice however to have a small test case ...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14236 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| c81436d329fa0be3dfb4c2bfd1b4783e0489884f |
|
15-Jul-2014 |
mjw <mjw@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
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| e2d41dc65a214f6950f42d0b02cd9cc2d932d927 |
|
08-Jul-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Apply text_debug_bias to inline IP extracted from dwarf3
Without this biasing, inline info is not correct for shared objects.
Updated test varinfo5 to use --read-inline-info=yes and added
an inline test case.
Note: the varinfo reader does not understand the inlining info, and
so variables in inlined functions are not properly described.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14146 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 0ff164112b6a398fa7e60dffed3c2b6dcf9dda25 |
|
21-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Find the name of the inlined function through a DW_AT_specification
The name is not necessarily found in the abstract origin, it can be
in a referred to specification.
If both a name and a DW_AT_specification is found in the abstract origin,
the name will have priority over the name of the specification.
(unclear if that can happen)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14076 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| e1f94b89c69cb3a71dce6800f6dbf8d045d935f6 |
|
21-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This optimisation divides by 2.5 the time (user+sys) needed to read
the inlined info of a big executable.
On a slow pentium, reading the inline info now takes 5.5 seconds.
The optimisation consists in having per dw3 abbreviation a structure
allowing to skip efficiently the non interesting DIEs (i.e. the DIEs
the parse_inl_DIE is not interested in).
Mostly, the idea is to avoid calling the image abstraction, and replace
this by just advancing the cursor (i.e. addition rather than a bunch
of function calls to read the data).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14075 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| e0bd5910153720d5d15697db8063d0d4caa59d8f |
|
21-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Use macro TD3 defined as UNLIKELY(td3) for tracing
to be sure the compiler understands that usually, we do not trace
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14074 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 86be6ed340d2373ffded269f57aa87765430ddcc |
|
17-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
restructure dwarf3 DIE tracing
* add a trace_DIE function
* use it to trace a bad DIE
and to trace all DIEs that are (maybe) read
(due to the "avoid read twice" optimisation, the tracing was not
so easy to read anymore => add an explicit trace_DIE call at the beginning
of read_DIE)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14050 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| d16fb63bfee12beb45f85695b4aed7a18bde56e1 |
|
16-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
optimisation : avoid double reading of a DIE when the DIE will be parsed
by a DIE parser
Instead of pre-reading the DIE, first let the parser(s) possibly
parse the DIE. Read (to skip) the DIE data if no parser has parsed it.
OTherwise, just jump to the end of the DIE as established by the parser
that has read the DIE.
This slightly improves the reading of inlined info.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14049 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 5612d1a3bcfb43437890c6a27396b839b7c24ef9 |
|
16-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix random crash due to non-init inlparser when --read-var-info given but not --read-inline-info
Wrong place for the assertion for the inlparser
+ move the "zero the parsers" out of the "if VG_(clo*)" conditions
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14044 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 896a3bfd1b98aa3358a2e77be3bb728cb3d2926f |
|
15-Jun-2014 |
philippe <philippe@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
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| e504887521dfee904f4dcea3655515bc99a6801f |
|
15-Jun-2014 |
philippe <philippe@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
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 0d2ea9d1cfd6f1fff0992096c2d15881becfe2e1 |
|
15-Jun-2014 |
philippe <philippe@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
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| c9831572483ed485438553d4c39686605d2625d6 |
|
15-Jun-2014 |
philippe <philippe@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
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| 746e97e7098def65d59c79d5d661f9a757a837cd |
|
15-Jun-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
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
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| 8130f91dc99a9ad90e516f8b449970ddaeaee911 |
|
07-May-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
On a big application linking with gtk, using the compilation options
-ffunction-sections -fdata-sections and the linker option
-Wl,--gc-sections, --read-var-info=yes gives the following:
valgrind: m_debuginfo/d3basics.c:973 (vgModuleLocal_evaluate_GX): Assertion 'aMax == ~(Addr)0' failed.
host stacktrace:
==18521== at 0x38057C54: show_sched_status_wrk (m_libcassert.c:308)
==18521== by 0x38057F50: report_and_quit (m_libcassert.c:367)
==18521== by 0x38058151: vgPlain_assert_fail (m_libcassert.c:432)
==18521== by 0x3813F084: vgModuleLocal_evaluate_GX (d3basics.c:973)
==18521== by 0x38098300: data_address_is_in_var (debuginfo.c:2769)
==18521== by 0x38099E26: vgPlain_get_data_description (debuginfo.c:3298)
...
The problem is that -Wl,--gc-sections eliminates the unused functions
but keeps some debug info for the functions or their compilation units.
The dwarf entry has low and high pc, but both are equal to 0.
The dwarf reader of Valgrind is confused by this, as the varstack becomes
empty, while it should not. This then causes local (eliminated) variables
to be put in the global scope, leading afterwards to evaluation errors
when describing any other variables.
The fix is to also push something on the varstack when
a CU that has low and high pc given but with 0 value.
This is similar to the varstack_push done for a CU that has
no low pc, no high pc and no range.
Despite considerable effort to make a small reproducer, the problem
could only be produced with a big executable.
After the fix, everything was working properly.
The wrong behaviour for dwarf entries produce the following trace:
<2><2ff291a>: Abbrev Number: 23 (DW_TAG_formal_parameter)
DW_AT_name : AET
DW_AT_decl_file : 1
DW_AT_decl_line : 243
DW_AT_type : <2ff2811>
DW_AT_location : 18288554
Recording this variable, with 1 PC range(s)
....
<2ff291a> addVar: level 0: AET :: EdgeTableEntry*
Loc=GX(final){[0x0,0x8]=50,[0x9,0x1d]=53,[0x1e,0x26]=51,[0x27,0x29]=53,[0x2a,0x2f]=51,[0x44,0x4a]=53,[0x4d,0x5e]=51,[0x5f,0x62]=53}
FrB=none
declared at: gdkpolyreg-generic.c:243
ACQUIRE for range(s) [0x0,0xffffffff]
The AET is a formal parameter of a function, but is wrongly added
at level 0, with a PC range covering the full space. It has a Loc GX
which uses non biased program counters (e.g. 0x0,0x8).
This dwarf entry will require a FrB (and registers when evaluating)
but no such things are available (or given) when evaluating a variable
in the global scope.
The fix is to handle compilation units with lo and hi pc == 0x0
similarly to a CU that has no lo and hi pc.
With this fix, valgrind --read-var-info=yes could properly
handle a big application with plenty of eliminated functions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13941 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 5c5b8fc1da94607b804e408a38f073c4d6f3b76f |
|
06-May-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
For the following c program:
main(int argc)
{
typedef
struct {
int before_name;
char name[argc];
int after_name;
}
namet;
namet n;
}
compiled with gcc 4.7.4, the trunk --read-var-info=yes gives:
parse_type_DIE: confused by:
<2><51>: DW_TAG_structure_type
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_sibling : <83>
This is because that dwarf entry defines a struct with no size.
This happens when the struct has a VLA array in the middle
of a struct. This is a C gcc extension, and is a standard
feature of Ada.
The proper solution would be to have the size calculated at runtime,
using the gnat extensions or dwarf entries (to be generated by
the compiler).
The patch fixes this problem by defining the size of such structure
as 1 byte.
Another approach tried was to put the max possible size.
This had the disadvantage that any address on the stack was seen
as belonging to this variable.
This allows the description to work for the 1st byte of the variable
but cannot properly describe the 2nd and following bytes :
(gdb) p &n
$9 = (namet *) 0xbefbc070
(gdb) mo c d 0xbefbc070
Address 0xBEFBC070 len 1 not defined:
Uninitialised value at 0xBEFBC070
==1396== Location 0xbefbc070 is 0 bytes inside n.before_name,
==1396== declared at crec.c:10, in frame #0 of thread 1
(gdb) mo c d 0xbefbc071
Address 0xBEFBC071 len 1 not defined:
Uninitialised value at 0xBEFBC071
==1396== Address 0xbefbc071 is on thread 1's stack
(gdb)
A possible refinement would be to use a huge size but have the
logic of variable description understanding this and describing
all between this var and hte next var on the stack as being
in the VLA variable.
In the meantime, the size 1 avoids --read-var-info=yes to fail.
Also, the 'goto bad_DIE' have been replaced by a macro
goto_bad_DIE that ensures the line nr at which the bad DIE has
been detected is reported in the error msg.
This makes it easier to understand what is the problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13938 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 0abc4193f82294904ed9478fa80394224c03fcc0 |
|
04-Apr-2014 |
dejanj <dejanj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
mips32/64: According to DWARF version 4 in DW_TAG_structure_type we can
have DW_AT_signature attribute. That wasn't the case in DWARF version 3.
From DWARF version 4:
If the complete declaration of a type has been placed in a separate type unit,
an incomplete declaration of that type in the compilation unit may provide the
unique 64-bit signature of the type using a DW_AT_signature attribute.
This patch adds an extra field in TyStOrUn structure (typeR). This field is
reference to other TyEnt that is placed in separate type unit. Because of the new
field in TyStOrUn structure we need to add an extra case in parse_type_DIE
that will put the right reference to other TyEnt and an extra case in
ML_(describe_type) that will describe type when the ty->Te.TyStOrUn.typeR field
is used.
This patch is resolving the problem with memcheck/tests/dw4 test when it's
compiled with compiler that will emit DW_AT_signature under the DW_TAG_structure_type.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13891 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| e5cf4510a6c26279e0b7f625dc615f94b8fbdebf |
|
24-Nov-2013 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bug 327916 - DW_TAG_typedef may have no name
We already accepted DW_TAG_typedef without a name for Ada. But g++ for
OpenMP can also emit such nameless DW_TAG_typedefs. Just accept them.
Also fix up anonymous enum and typedef printing in tytypes.c.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13718 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.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
|
| 9d82d0f293c83ff2b8c3ab07065d8454059452be |
|
28-Jun-2013 |
mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Bug 289360 parse_type_DIE confused by DW_TAG_enumeration_type.
GCC allows incomplete enums as GNU extension.
http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html
These are marked as DW_AT_declaration and won't have a size.
They can only be used in declaration or as pointer types.
You can't allocate variables or storage using such an enum type.
So don't require a size for such enum types.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13433 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 81d24c396c66dde7db2d9b567451f99081a2eab7 |
|
05-Dec-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
fix 310424 --read-var-info does not properly describe static variables
This patch changes the way static variables are
recorded by readdwarf3.c (when giving --read-var-info=yes),
improving the way such variables are described.
Currently:
A static variable does not have the DW_AT_external tag.
So, readdwarf3.c does not consider it a global variable.
It is rather considered a "local" variable.
When it is recorded, it is associated to a range of program counters
(the functions in the file where it is visible).
However, even if the static variable is only visible
in the source file where it is declared, it can in reality
be used by any range of program counters, typically
by having the address of the local variable passed
to other functions.
Such local variable can then only be described
when the program counter is in the range of program
counters for which it has been recorded.
However, this (local) description is obtained
by a kludge in debuginfo.c (around line 3285).
This kludge then produces a strange description,
telling that the variable has been declared in
frame 0 of a thread (see second example below).
The kludge is not always able to describe
the address (if the IP of the tid is in another file than
where the variable has been declared).
I suspect the kludge can sometimes describe the var as being
declared in an unrelated thread
(e.g. if an error is triggered by tid 5, but tid1 is by
luck in an IP corresponding to the recorded range).
The patch changes the way a static variable is recorded:
if DW_AT_external tag is found, a variable is marked as global.
If a variable is not external, but is seen when level is 1,
then we record the variable as a global variable (i.e.
with a full IP range).
This improves the way such static variable are described:
* they are described even if being accessed by other files.
* their description is not in an artificial "thread frame".
First example:
**************
a variable cannot be described because it is
accessed by a function in another file:
with the trunk:
==20410== ----------------------------------------------------------------
==20410==
==20410== Possible data race during read of size 4 at 0x600F54 by thread #1
==20410== Locks held: none
==20410== at 0x4007E4: a (abc.c:42)
==20410== by 0x4006BC: main (mabc.c:24)
==20410==
==20410== This conflicts with a previous write of size 4 by thread #2
==20410== Locks held: none
==20410== at 0x4007ED: a (abc.c:42)
==20410== by 0x400651: brussels_fn (mabc.c:9)
==20410== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==20410== by 0x4E348C9: start_thread (pthread_create.c:300)
==20410==
==20410== ----------------------------------------------------------------
with the patch:
==4515== ----------------------------------------------------------------
==4515==
==4515== Possible data race during read of size 4 at 0x600F54 by thread #1
==4515== Locks held: none
==4515== at 0x4007E4: a (abc.c:42)
==4515== by 0x4006BC: main (mabc.c:24)
==4515==
==4515== This conflicts with a previous write of size 4 by thread #2
==4515== Locks held: none
==4515== at 0x4007ED: a (abc.c:42)
==4515== by 0x400651: brussels_fn (mabc.c:9)
==4515== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==4515== by 0x4E348C9: start_thread (pthread_create.c:300)
==4515==
==4515== Location 0x600f54 is 0 bytes inside global var "static_global"
==4515== declared at mabc.c:4
==4515==
==4515== ----------------------------------------------------------------
Second example:
***************
When the kludge can describe the variable, it is strangely described
as being declared in a frame of a thread, while for sure the declaration
has nothing to do with a thread
With the trunk:
==20410== Location 0x600f68 is 0 bytes inside local var "static_global_a"
==20410== declared at abc.c:3, in frame #0 of thread 1
With the patch:
==4515== Location 0x600f68 is 0 bytes inside global var "static_global_a"
==4515== declared at abc.c:3
#include <stdio.h>
static int static_global_a = 0; //// <<<< this is abc.c:3
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13153 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 3e7986312a0ffc7646b0552d4c4ea3744a870e73 |
|
24-Nov-2012 |
florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix some casts that removed const-ness as pointed out by
GCC's -Wcast-qual.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13138 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.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/readdwarf3.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/readdwarf3.c
|
| f7c9714ea0cde18daaecb896278e85e780d3bd75 |
|
14-Jul-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Initial support for DWZ compressed debuginfo -- don't crash, at least,
when reading it. Bug 302901 comment 3. (Jakub Jelinek, jakub@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12742 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 00888885d88a5264711c22074cfd3462020cbee6 |
|
30-Jun-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Don't be spooked by DW_TAG_{structure,class,union}_type that has only
a DW_AT_declaration but no name. Just make up a name and add the
type.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12691 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| de065a05bd7e802669c9074b129268bd9a5c308c |
|
10-May-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Support DWARF version 4 DW_AT_high_pc constant form. #299053.
(Mark Wielaard, mjw@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12558 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| ee93cdbee1e6a0db21be1ec4533a4022c9566388 |
|
29-Apr-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Correctly parse DW_FORM_ref_addr -- its format is different in Dwarf2
vs Dwarf3 and later. Fixes #298864. (Tom Tromey, tromey@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12545 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| d935068fc7b53c8a826b3436cdfccd5b7d446903 |
|
05-Apr-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add support for reading DWARF4 .debug_types sections. Fixes #284124.
(Tom Tromey, tromey@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12491 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 471d6b3eba2d617279c3954a13e322174a0eec13 |
|
05-Apr-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix incorrect use of VG_(addToXA). (Tom Tromey <tromey@redhat.com>)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12490 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| a2af13d238de6b212f1d69e7b316538f37a7abba |
|
04-Apr-2012 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Comment-only fix. (Tom Tromey <tromey@redhat.com>)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12487 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 4bad5933e7b59ab9c756fb71da0f7fea7c4e61f0 |
|
06-Mar-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix leak of range_list (see below an example) in readdwarf3.c.
(found by running regression tests with an outer memcheck).
(validated by running all regression tests "natively" on x86 and amd64,
and re-running regressions tests with outer memcheck).
==7500== 160 bytes in 2 blocks are definitely lost in loss record 75 of 246
==7500== at 0x2803CEF7: vgPlain_arena_malloc (m_mallocfree.c:1599)
==7500== by 0x280AAFA5: vgModuleLocal_dinfo_zalloc (misc.c:48)
==7500== by 0x2804E2A4: vgPlain_newXA (m_xarray.c:68)
==7500== by 0x280B3CD6: unitary_range_list (readdwarf3.c:703)
==7500== by 0x280B66CF: parse_var_DIE (readdwarf3.c:1631)
==7500== by 0x280BA0A6: read_DIE (readdwarf3.c:3248)
==7500== by 0x280BA170: read_DIE (readdwarf3.c:3269)
==7500== by 0x280BABC4: T.364 (readdwarf3.c:3611)
==7500== by 0x280BC634: vgModuleLocal_new_dwarf3_reader (readdwarf3.c:4035)
==7500== by 0x280609F4: vgModuleLocal_read_elf_debug_info (readelf.c:2529)
==7500== by 0x2805BD31: vgPlain_di_notify_mmap (debuginfo.c:610)
==7500== by 0x280362E3: valgrind_main (m_main.c:1944)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12419 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| d9df0ea979e3dd5b732b8cced076a105fa45f352 |
|
28-Feb-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fix leak found by running memcheck/tests/varinfo[1-6].vgtest
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12409 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 0e947cfedebda6da2e84fb61af431db5cf1275fc |
|
01-Feb-2012 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
debug info reader: Add support for rvalue references. Closes #278313#c5.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12362 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| e64c5a9a6c0d9c87bc7a65629455d2ff7fb9bda4 |
|
16-Jan-2012 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
debug info reader: Add support for DW_TAG_unspecified_type. Closes #278313.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12338 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| 86781fabbfc019b752f9605e487cfce77b2a592a |
|
05-Oct-2011 |
tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
More fixes for unaligned accesses in the debuginfo code. BZ#282527.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12102 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 97d3ebba515c00930db4ee3f52af571bc84b2ef6 |
|
11-Apr-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add an alternative implementation of VG_MINIMAL_{SET,LONG}JMP
for ppc32-linux, that works for gcc >= 4.4. Related to #259977.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11688 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 6c591e15c1d6402a2a755310f005f795b68e7e38 |
|
11-Apr-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Create new module m_libcsetjmp, which wraps up uses of
__builtin_setjmp and __builtin_longjmp so that they can be selectively
replaced, on a platform by platform basis. Does not change any
functionality. Related to #259977.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11687 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 2acc87cac77cedb3884e9e3a5188bac6edda5aee |
|
02-Feb-2011 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle Dwarf3 types created by GNAT. Fixes #255130.
(Philippe Waroquiers <philippe.waroquiers@skynet.be>)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11517 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 50c5093772c2b23fd0897d3590dcfaec1c92ac83 |
|
18-Oct-2010 |
tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add support for DW_ATE_UTF from DWARF4 which is needed for char16_t
support in C++0X.
Patch from Christian Borntraeger on bug #254550.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11450 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| a6f76eebd1d0bca59ca88b98e88e909086e8c9fa |
|
11-Oct-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Remove some fluff detected by llvm-2.8 (clang):
- "*(int *)0 = " is apparently ignored by LLVM for who-knows-why
reason. Cast the zero to a volatile int * instead.
- remove an unused function that gcc failed to mention was unused
(why? because it was marked __attribute__((noreturn)) ?)
As an aside, clang/llvm-2.8 seemed to be able to successfully
compile Valgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11429 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| bdee918842b4b2d4a09146a4642e999dc71b3652 |
|
09-Oct-2010 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Dwarf3 reader: handle Dwarf3 created by gcc-4.5.1. In other words,
work around the all-new-buggy-Dwarf3 created by gcc-4.5.1.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11418 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| fba428cd266b8a39db641c5fd9523daa8939bed0 |
|
28-Apr-2010 |
tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Add some basic DWARF4 support. Based on patch from Jakub Jelinek
but with support for VLIW architectures with multiple opcodes per
instruction removed. Fixes #233595.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11106 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| b34bb1d378ba9e5b09e993ed9adbfaf151238878 |
|
10-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
parse_type_DIE: push incomplete structure tyents on the type stack,
since gcc-4.4 on Fedora 11 will create DW_TAG_member entries within
it, and we need to have a plausible parent type on the stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10770 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 07de5ddba10bfebab8416a8f79c349faa62bbaa1 |
|
03-Aug-2009 |
tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Ignore structure members with no location - thiscan happen with static
const members in C++ code which are compile time constants that do no
exist in the class. They're not of any interest to us so we ignore them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10698 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| d8011772ac0520edc193899f995e166ba70f14e9 |
|
03-Aug-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Use Dwarf3 section version numbers as specified in Appendix F of the
Dwarf3 standard. (Jakub Jelinek). This is #200029, patch in comment
#1.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10696 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 72259920f8cad01708271879caca023969463d16 |
|
03-Aug-2009 |
tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle some more DW_TAG_subrange_type cases which Fedora 11's
gcc 4.4.0 seems to generate.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10695 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| 8b68b64759254d514d98328c496cbd88cde4c9a5 |
|
24-Jun-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This commit merges the BUILD_TWEAKS branch onto the trunk. It has the
following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.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/readdwarf3.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/readdwarf3.c
|
| 402c9eed11b9b60c6e134d05db938e395466cf99 |
|
09-Mar-2009 |
tom <tom@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Keep track of the svma and bias values for the debug data separately
as they may be different to those for other sections of the ELF file
if we have separated debug information and the main file has been
prelinked since they were split. Fixes bug #185816.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9329 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 31452303b095a76295b08096b2840276db808b81 |
|
26-Jan-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle a couple of artefacts produced by icc11: DW_TAG_reference_type
that doesn't have a size, and DW_FORM_ref_addr (assuming my
interpretation of the standard is correct.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9058 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 6ece231961274337eb8303aba3ac5247fc7d1ef9 |
|
24-Jan-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Accept 'enum' type DIEs that do not have any names; apparently Dwarf2
allows this. Patch from Nuno Lopes. #181707.
MERGE TO 3_4_BRANCH
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9055 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 055b0f85aaa42477a803d445885c389561d3d3c8 |
|
24-Jan-2009 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle the case where a Compilation Unit (CU) (or, really, the CU and
its associated DIEs) occupies less space than stated in the CU's
header. icc9 appears to produce CUs with this anomaly. Not handling
the case causes the reader to lose sync at the start of the following
CU, since it hasn't skipped the junk bytes at the end of the current
CU, and it is basically hosed after that.
MERGE TO 3_4_BRANCH (?)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9049 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| c4431bfe04c7490ea2d74939d222d87f13f30960 |
|
15-Jan-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Introduce a new type, PtrdiffT. Replace lots of uses of OffT (all those
that are memory offsets) with PtrdiffT; OffT should only be used for file
sizes and offsets.
Change Off64T from a ULong to a Long, as it should be. Replace some uses
of ULong in the address space manager with Off64T to match.
Also add a comment explaining the meanings of the basic types like Addr,
OffT, SizeT, etc.
Also fix the prototype for VG_(pread) -- the last arg is an OffT, not an
Int.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8959 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| b2250d38b573099db3bde67e8f1bbeb789542076 |
|
23-Oct-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
get_Form_contents: handle DW_FORM_block2.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8701 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| f3aaa337f0bd3084b339cdcff58ef6fef25bf15f |
|
23-Oct-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Tolerate apparently broken Dwarf3 generated by gcc (GCC) 4.4.0
20081017 (experimental): accept DW_TAG_enumerator with only a
DW_AT_name but no DW_AT_const_value. This is in violation of the
Dwarf3 standard.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8700 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 3d3380f5a5c8ff0b85b35ae442eba0b4f68422db |
|
22-Oct-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Don't assert on icc9 generated Dwarf3.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8696 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| 59a2d18d0ddfa241850017252b0804d469187d79 |
|
23-Aug-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Rework storage management in the Dwarf3 type and variable reader, to
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 6a3a28409187ca6813b228afaf2af288c1fcd73d |
|
20-Aug-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Make the absolute bare minimum changes needed to stop the Dwarf3
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|
| f578a69a862391896fa2f03359c3744022ae9783 |
|
24-Jun-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle apparently-bogus DW_TAG_compilation_unit DIE that shows up in
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 7cf4e6b6aed533af53339f36099ed244dc4a5b7f |
|
01-May-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge branches/OTRACK_BY_INSTRUMENTATION into the trunk. This adds
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 68a2ebd9384661a85a4674fe8310c595ad494305 |
|
07-Mar-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Try to handle the situation where an object is first split into a base
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| 0b5bf911d9d40b8dd3130f6043ef7ba68a9f446e |
|
07-Mar-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Handle DW_FORM_data8.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7589 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.c
|
| aed2e4cd72d04f375cbc3bceb05e5b2d909483ee |
|
03-Mar-2008 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Compiles now with gcc 2.96 too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7550 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/coregrind/m_debuginfo/readdwarf3.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/readdwarf3.c
|