mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-10 21:47:06 +00:00
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
This commit is contained in:
Philippe Waroquiers
@@ -1780,6 +1780,50 @@ need to use them.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="opt.read-inline-info" xreflabel="--read-inline-info">
|
||||
<term>
|
||||
<option><![CDATA[--read-inline-info=<yes|no> [default: no] ]]></option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>When enabled, Valgrind will read information about
|
||||
inlined function calls from DWARF3 debug info.
|
||||
This slows Valgrind startup and makes it use more memory (typically
|
||||
for each inlined piece of code, 6 words + the function name), but
|
||||
it results in more descriptive stacktraces:</para>
|
||||
<programlisting><![CDATA[
|
||||
==15380== Conditional jump or move depends on uninitialised value(s)
|
||||
==15380== at 0x80484EA: main (inlinfo.c:6)
|
||||
==15380==
|
||||
==15380== Conditional jump or move depends on uninitialised value(s)
|
||||
==15380== at 0x8048550: fun_noninline (inlinfo.c:6)
|
||||
==15380== by 0x804850E: main (inlinfo.c:34)
|
||||
==15380==
|
||||
==15380== Conditional jump or move depends on uninitialised value(s)
|
||||
==15380== at 0x8048520: main (inlinfo.c:6)]]></programlisting>
|
||||
|
||||
<para>And here are the same errors with
|
||||
<option>--read-inline-info=yes</option>:</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
==15377== Conditional jump or move depends on uninitialised value(s)
|
||||
==15377== at 0x80484EA: fun_d (inlinfo.c:6)
|
||||
==15377== by 0x80484EA: fun_c (inlinfo.c:14)
|
||||
==15377== by 0x80484EA: fun_b (inlinfo.c:20)
|
||||
==15377== by 0x80484EA: fun_a (inlinfo.c:26)
|
||||
==15377== by 0x80484EA: main (inlinfo.c:33)
|
||||
==15377==
|
||||
==15377== Conditional jump or move depends on uninitialised value(s)
|
||||
==15377== at 0x8048550: fun_d (inlinfo.c:6)
|
||||
==15377== by 0x8048550: fun_noninline (inlinfo.c:41)
|
||||
==15377== by 0x804850E: main (inlinfo.c:34)
|
||||
==15377==
|
||||
==15377== Conditional jump or move depends on uninitialised value(s)
|
||||
==15377== at 0x8048520: fun_d (inlinfo.c:6)
|
||||
==15377== by 0x8048520: main (inlinfo.c:35)
|
||||
]]></programlisting>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id="opt.read-var-info" xreflabel="--read-var-info">
|
||||
<term>
|
||||
<option><![CDATA[--read-var-info=<yes|no> [default: no] ]]></option>
|
||||
@@ -1787,36 +1831,39 @@ need to use them.</para>
|
||||
<listitem>
|
||||
<para>When enabled, Valgrind will read information about
|
||||
variable types and locations from DWARF3 debug info.
|
||||
This slows Valgrind down and makes it use more memory, but for
|
||||
the tools that can take advantage of it (Memcheck, Helgrind,
|
||||
DRD) it can result in more precise error messages. For example,
|
||||
This slows Valgrind startup significantly and makes it use significantly
|
||||
more memory, but for the tools that can take advantage of it (Memcheck,
|
||||
Helgrind, DRD) it can result in more precise error messages. For example,
|
||||
here are some standard errors issued by Memcheck:</para>
|
||||
<programlisting><![CDATA[
|
||||
==15516== Uninitialised byte(s) found during client check request
|
||||
==15516== at 0x400633: croak (varinfo1.c:28)
|
||||
==15516== by 0x4006B2: main (varinfo1.c:55)
|
||||
==15516== Address 0x60103b is 7 bytes inside data symbol "global_i2"
|
||||
==15516==
|
||||
==15516== Uninitialised byte(s) found during client check request
|
||||
==15516== at 0x400633: croak (varinfo1.c:28)
|
||||
==15516== by 0x4006BC: main (varinfo1.c:56)
|
||||
==15516== Address 0x7fefffefc is on thread 1's stack]]></programlisting>
|
||||
==15363== Uninitialised byte(s) found during client check request
|
||||
==15363== at 0x80484A9: croak (varinfo1.c:28)
|
||||
==15363== by 0x8048544: main (varinfo1.c:55)
|
||||
==15363== Address 0x80497f7 is 7 bytes inside data symbol "global_i2"
|
||||
==15363==
|
||||
==15363== Uninitialised byte(s) found during client check request
|
||||
==15363== at 0x80484A9: croak (varinfo1.c:28)
|
||||
==15363== by 0x8048550: main (varinfo1.c:56)
|
||||
==15363== Address 0xbea0d0cc is on thread 1's stack
|
||||
==15363== in frame #1, created by main (varinfo1.c:45)
|
||||
></programlisting>
|
||||
|
||||
<para>And here are the same errors with
|
||||
<option>--read-var-info=yes</option>:</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
==15522== Uninitialised byte(s) found during client check request
|
||||
==15522== at 0x400633: croak (varinfo1.c:28)
|
||||
==15522== by 0x4006B2: main (varinfo1.c:55)
|
||||
==15522== Location 0x60103b is 0 bytes inside global_i2[7],
|
||||
==15522== a global variable declared at varinfo1.c:41
|
||||
==15522==
|
||||
==15522== Uninitialised byte(s) found during client check request
|
||||
==15522== at 0x400633: croak (varinfo1.c:28)
|
||||
==15522== by 0x4006BC: main (varinfo1.c:56)
|
||||
==15522== Location 0x7fefffefc is 0 bytes inside local var "local"
|
||||
==15522== declared at varinfo1.c:46, in frame #1 of thread 1]]></programlisting>
|
||||
==15370== Uninitialised byte(s) found during client check request
|
||||
==15370== at 0x80484A9: croak (varinfo1.c:28)
|
||||
==15370== by 0x8048544: main (varinfo1.c:55)
|
||||
==15370== Location 0x80497f7 is 0 bytes inside global_i2[7],
|
||||
==15370== a global variable declared at varinfo1.c:41
|
||||
==15370==
|
||||
==15370== Uninitialised byte(s) found during client check request
|
||||
==15370== at 0x80484A9: croak (varinfo1.c:28)
|
||||
==15370== by 0x8048550: main (varinfo1.c:56)
|
||||
==15370== Location 0xbeb4a0cc is 0 bytes inside local var "local"
|
||||
==15370== declared at varinfo1.c:46, in frame #1 of thread 1
|
||||
]]></programlisting>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user