zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-05 11:10:21 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
ftmemsim-valgrind/coregrind/pub_core_debuginfo.h
Philippe Waroquiers ceaa5b2efe 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
2014-06-15 15:42:20 +00:00

177 lines
7.0 KiB
C
Raw Blame History

/*--------------------------------------------------------------------*/
/*--- Debug info. pub_core_debuginfo.h ---*/
/*--------------------------------------------------------------------*/
/*
This file is part of Valgrind, a dynamic binary instrumentation
framework.
Copyright (C) 2000-2013 Julian Seward
jseward@acm.org
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307, USA.
The GNU General Public License is contained in the file COPYING.
*/
#ifndef __PUB_CORE_DEBUGINFO_H
#define __PUB_CORE_DEBUGINFO_H
//--------------------------------------------------------------------
// PURPOSE: This module deals with reading debug info and symbol tables
// to get file and function names, line numbers, variable types, and
// to help stack unwinding.
//--------------------------------------------------------------------
#include "pub_tool_debuginfo.h"
/* Initialise the entire module. Must be called first of all. */
extern void VG_(di_initialise) ( void );
/* LINUX: Notify the debuginfo system about a new mapping, or the
disappearance of such, or a permissions change on an existing
mapping. This is the way new debug information gets loaded. If
allow_SkFileV is True, it will try load debug info if the mapping
at 'a' belongs to Valgrind; whereas normally (False) it will not do
that. This allows us to carefully control when the thing will read
symbols from the Valgrind executable itself.
If a call to VG_(di_notify_mmap) causes debug info to be read, then
the returned ULong is an abstract handle which can later be used to
refer to the debuginfo read as a result of this specific mapping,
in later queries to m_debuginfo. In this case the handle value
will be one or above. If the returned value is zero, no debug info
was read.
For VG_(di_notify_mmap), if use_fd is not -1, that is used instead
of the filename; this avoids perturbing fcntl locks, which are
released by simply re-opening and closing the same file (even via
different fd!).
*/
#if defined(VGO_linux) || defined(VGO_darwin)
extern ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd );
extern void VG_(di_notify_munmap)( Addr a, SizeT len );
extern void VG_(di_notify_mprotect)( Addr a, SizeT len, UInt prot );
/* this should really return ULong, as per VG_(di_notify_mmap). */
extern void VG_(di_notify_pdb_debuginfo)( Int fd, Addr avma,
SizeT total_size,
PtrdiffT bias );
/* this should also really return ULong */
extern void VG_(di_notify_vm_protect)( Addr a, SizeT len, UInt prot );
#endif
extern void VG_(di_discard_ALL_debuginfo)( void );
/* Like VG_(get_fnname), but it does not do C++ demangling nor Z-demangling
* nor below-main renaming.
* It should not be used for any names that will be shown to users.
* It should only be used in cases where the names of interest will have
* particular (ie. non-mangled) forms, or the mangled form is acceptable. */
extern
Bool VG_(get_fnname_raw) ( Addr a, HChar* buf, Int nbuf );
/* Like VG_(get_fnname), but without C++ demangling. (But it does
Z-demangling and below-main renaming.)
iipc argument: same usage as in VG_(describe_IP) in pub_tool_debuginfo.h. */
extern
Bool VG_(get_fnname_no_cxx_demangle) ( Addr a, HChar* buf, Int nbuf,
InlIPCursor* iipc );
/* mips-linux only: find the offset of current address. This is needed for
stack unwinding for MIPS.
*/
extern
Bool VG_(get_inst_offset_in_function)( Addr a, /*OUT*/PtrdiffT* offset );
/* Use DWARF2/3 CFA information to do one step of stack unwinding.
D3UnwindRegs holds the current register values, and is
arch-specific. Note that the x86 and amd64 definitions are shared
and so the regs are named 'xip' etc rather than 'eip' and 'rip'. */
#if defined(VGA_amd64) || defined(VGA_x86)
typedef
struct { Addr xip; Addr xsp; Addr xbp; }
D3UnwindRegs;
#elif defined(VGA_arm)
typedef
struct { Addr r15; Addr r14; Addr r13; Addr r12; Addr r11; Addr r7; }
D3UnwindRegs;
#elif defined(VGA_arm64)
typedef
struct { Addr pc; Addr sp; Addr x30; Addr x29; } /* PC, SP, LR, FP */
D3UnwindRegs;
#elif defined(VGA_ppc32) || defined(VGA_ppc64)
typedef
UChar /* should be void, but gcc complains at use points */
D3UnwindRegs;
#elif defined(VGA_s390x)
typedef
struct { Addr ia; Addr sp; Addr fp; Addr lr;}
D3UnwindRegs;
#elif defined(VGA_mips32) || defined(VGA_mips64)
typedef
struct { Addr pc; Addr sp; Addr fp; Addr ra; }
D3UnwindRegs;
#else
# error "Unsupported arch"
#endif
extern Bool VG_(use_CF_info) ( /*MOD*/D3UnwindRegs* uregs,
Addr min_accessible,
Addr max_accessible );
/* returns the "generation" of the CF info.
Each time some debuginfo is changed (e.g. loaded or unloaded),
the VG_(CF_info_generation) value returned will be increased.
This can be used to flush cached information derived from the CF info. */
extern UInt VG_(CF_info_generation) (void);
/* Use MSVC FPO data to do one step of stack unwinding. */
extern Bool VG_(use_FPO_info) ( /*MOD*/Addr* ipP,
/*MOD*/Addr* spP,
/*MOD*/Addr* fpP,
Addr min_accessible,
Addr max_accessible );
/* ppc64-linux only: find the TOC pointer (R2 value) that should be in
force at the entry point address of the function containing
guest_code_addr. Returns 0 if not known. */
extern Addr VG_(get_tocptr) ( Addr guest_code_addr );
/* Map a function name to its entry point and toc pointer. Is done by
sequential search of all symbol tables, so is very slow. To
mitigate the worst performance effects, you may specify a soname
pattern, and only objects matching that pattern are searched.
Therefore specify "*" to search all the objects. On TOC-afflicted
platforms, a symbol is deemed to be found only if it has a nonzero
TOC pointer. */
extern
Bool VG_(lookup_symbol_SLOW)(const HChar* sopatt, HChar* name, Addr* pEnt,
Addr* pToc);
#endif // __PUB_CORE_DEBUGINFO_H
/*--------------------------------------------------------------------*/
/*--- end ---*/
/*--------------------------------------------------------------------*/
Reference in New Issue View Git Blame Copy Permalink