This is a supplement to commit 86277041
To improve its results, Callgrind does special handling for
the runtime linker entry point to resolve symbols. However,
it only used the exact symbol name "_dl_runtime_resolve",
as well as specific machine code templates (when the runtime
linker was stripped from symbol names) as basis.
Recent glibc added multiple similar symbol names as variants,
such as _dl_runtime_resolve_xsave.
The above-mentioned commit 86277041 solves this by extending
the check for machine code templates for specific Linux
distributions.
This patch extends this for more architectures and variants
by checking if a function starts with "_dl_runtime_resolve".
Furthermore, the original function names of the variants
still are visible in the output (and not forced to the prefix).
While the heuristic that every function symbol starting
with the prefix "_dl_runtime_resolve" as being an entry point
into the runtime linker for resolving a function address may
be a bit rough, this prefix is not expected to be used often in
other source code for anything else.
The worst case is a slightly misleading call graph only
visible in a very specific situation: if the wrongly-detected
function does a tail call (ie instead of returning, jumping
to another function), it will be shown as 2 calls in a row
from the original caller.
Newer glibc have alternate ld.so _ld_runtime_resolve functions.
Namely _dl_runtime_resolve_xsave and _dl_runtime_resolve_xsavec
This patch recognizes the xsave, xsvec and fxsave variants and
changes callgrind so that any variant counts as _dl_runtime_resolve.
Original patch by paulo.cesar.pereira.de.andrade@gmail.comhttps://bugs.kde.org/show_bug.cgi?id=415293
Sync VEX/LICENSE.GPL with top-level COPYING file. We used 3 different
addresses for writing to the FSF to receive a copy of the GPL. Replace
all different variants with an URL <http://www.gnu.org/licenses/>.
The following files might still have some slightly different (L)GPL
copyright notice because they were derived from other programs:
- files under coregrind/m_demangle which come from libiberty:
cplus-dem.c, d-demangle.c, demangle.h, rust-demangle.c,
safe-ctype.c and safe-ctype.h
- coregrind/m_demangle/dyn-string.[hc] derived from GCC.
- coregrind/m_demangle/ansidecl.h derived from glibc.
- VEX files for FMA detived from glibc:
host_generic_maddf.h and host_generic_maddf.c
- files under coregrin/m_debuginfo derived from LZO:
lzoconf.h, lzodefs.h, minilzo-inl.c and minilzo.h
- files under coregrind/m_gdbserver detived from GDB:
gdb/signals.h, inferiors.c, regcache.c, regcache.h,
regdef.h, remote-utils.c, server.c, server.h, signals.c,
target.c, target.h and utils.c
Plus the following test files:
- none/tests/ppc32/testVMX.c derived from testVMX.
- ppc tests derived from QEMU: jm-insns.c, ppc64_helpers.h
and test_isa_3_0.c
- tests derived from bzip2 (with embedded GPL text in code):
hackedbz2.c, origin5-bz2.c, varinfo6.c
- tests detived from glibc: str_tester.c, pth_atfork1.c
- test detived from GCC libgomp: tc17_sembar.c
- performance tests derived from bzip2 or tinycc (with embedded GPL
text in code): bz2.c, test_input_for_tinycc.c and tinycc.c
the dirname_available parameter. It's redundant. The value
of the returned directory name can be tested instead.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14814
The functions VG_(get_filename) and VG_(get_filename_lineno) now return
a pointer to filename and directory name instead of copying them into
buffers passed in from the caller.
The returned strings are persistent as long as the DebugInfo to which
they belong is not discarded. The caller therefore needs to stash them
away as needed.
Function VG_(strncpy_safely) has been removed as it is no longer needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14668
Change CLG_(get_debug_info) to not build up an absolute pathname in its
'file' parameter. Instead give it an additional parameter to hold the
directory name. Callers can then build up the absolute pathname if needed.
This change will come in handy soonish when VG_(get_filename_lineno) will be
changed and those buffers will disappear.
The change has a bit of ripple to get_fn_node_inseg and CLG_(get_file_node).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14666
This patch changes the interface and behaviour of VG_(demangle) and
VG_(maybe_Z_demangle). Instead of copying the demangled name into a
fixed sized buffer that is passed in from the caller (HChar *buf, Int n_buf),
the demangling functions will now return a pointer to the full-length
demangled name (HChar **result). It is the caller's responsiblilty to
make a copy if needed.
This change in function parameters ripples upward
- first: to get_sym_name
- then to the convenience wrappers
- VG_(get_fnname)
- VG_(get_fnname_w_offset)
- VG_(get_fnname_if_entry)
- VG_(get_fnname_raw)
- VG_(get_fnname_no_cxx_demangle)
- VG_(get_datasym_and_offset)
The changes in foComplete then forces the arguments of
- VG_(get_objname) to be changed as well
There are some issues regarding the ownership and persistence of
character strings to consider.
In general, the returned character string is owned by "somebody else"
which means the caller must not free it. Also, the caller must not
modify the returned string as it possibly points to read only memory.
Additionally, the returned string is not necessarily persistent. Here are
the scenarios:
- the returned string is a demangled function name in which case the
memory holding the string will be freed when the demangler is called again.
- the returned string hangs off of a DebugInfo structure in which case
it will be freed when the DebugInfo is discarded
- the returned string hangs off of a segment in the address space manager
in which case it may be overwritten when the segment is merged with
another segment
So the rule of thunb here is: if in doubt strdup the string.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14664
* VG_(find_seginfo): incrementally rearrange the DebugInfo list, like
most of the other list-searching functions do.
* rename all VG_(*seginfo*) functions exported from m_debuginfo to
VG_(*DebugInfo*). "seginfo" was a historical name which was mostly
but not completely, done away with some time back.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10678
OpenSuse 11.0 has glibc 2.8, which changed the assembly code for
runtime_resolve. This patch rearranges the code search such that
multiple variants can be scanned.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8841
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
Prepend the file name of a source file with the directory
if that is available. This not only gets rid of problems with the
same file name used in different paths of a project, but lets
the annotation work out of the box without having to specify any
source directory.
Works both with callgrind_annotate and KCachegrind without any
changes there.
Inspired by Nick's change to cachegrind doing the same thing
in r6839 (and gets rid of a FIXME in the source)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6850
This adds an option to change the default handling of jumps
between functions. Usually, a jump between functions is
interpreted as call, because such jumps are typically
generated by compilers on tail recursion optimization, and
we want to present this as call to the user. Thus, such
a jump pushes a call onto callgrinds shadow stack.
The option "--pop-on-jump" changes this to pop+push the
shadow callstack: then, a jump between functions is seen
as a return to the caller and a new call.
The default behaviour is _bad_ for using callgrind with
self-hosting. Valgrinds inner loop VG_(run_innerloop)
jumps to generated code, and this code jumps back to
the inner loop. Thus, every executed BB adds 2 calls
to an ever increasing shadow call stack, leading to
memory consumption increasing with runtime :-(
So: For self-hosting valgrind with an outer callgrind,
always use option "--pop-on-jump" for the outer callgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5869
