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
