KCachegrind currently uses a quick format detection before
actually loading a file, and checks for a line starting with
"events:" in the first 2kB for that. This obviously is fragile,
as shown by an internal bug report by Philippe: before the
"events" line, Callgrind puts a "cmd:" line with the command
line. If this is very long, the detection fails and the file
does not get loaded at all.
While KCachegrind would not need to have this quick format
check at all, it is useful if multiple input format filters
get supported at some point, to automatically select the
correct filter.
Further, for the "file" command, for file managers and
desktop environments, having an unique way to detect a
file format is important.
It is not too late to fix this issue for the callgrind format.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16196
* callgrind_annotate: ignore the lines giving the long names of the
events: such lines are used by kcachegrind for the GUI, so are better
accepted (and ignored) by callgrind_annotate
* Document in callgrind_annotate manual that thresholds can be given
per event kind.
* Avoid a division by zero in callgrind_annotate, for 'special data'
such as produced by (some) xtrees.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16125
At many places, we have:
VG_(fun(a,b,c))
instead of
VG_(fun)(a,b,c)
So, fix these cases, found using:
grep -n -i -e 'VG_([a-z][a-z0-9_]*[^a-z0-9_)]' *.c */*.c */*/*.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15776
Escape newlines in command arguments for "cmd:" header field in dumps
We could do unescaping in callgrind_annotate, but a escaped command
even seems better there.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14947
made from file-backed mappings (AOT code, basically) that is different
from the default behaviour as specified by --vex-iropt-register-updates.
New flag is --px-file-backed=, with the same possible args as
--vex-iropt-register-updates has.
Add a new flag --px-default, which is a short alias for
--vex-iropt-register-updates.
Add one line of stats output when --stats=yes, showing counts of how
many translations have been made under each of the 4 different PX
optimisation settings.
No user-visible change if you don't use the new flags.
Relies on VEX API change in r3084.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14906
only allowed to be called in certain contexts which is
enforced at runtime.
Change callgrind accordingly.
New header file pub_tool_transtab.h added.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14867
When the info struct for a BB is created, we use the first guest
instruction address as key to insert the info into a hash table.
We should do the same when discarding.
This actually is not a real problem, as Callgrind obviously
is used very rarely with redirections. But we should be consistent
with cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14856
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
VG_(debugLog_vprintf).
Remove function VG_(percentify) and fix up its call sites (part of
fixing BZ #337869.
Allow the width in a format specification to be '*', i.e. the width is
given as an additional function argument.
The limitations for printing floating point numbers are:
(1) %f is the only supported format. Width and precision can be
specified.
(2) Funny numbers (NaN and such) are not supported.
(3) Floating point numbers need to be benign in the sense that their
integral part fits into an ULong.
This is good enough for our purposes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14806
Two things:
- remove the buffer argument from VG_(DebugInfo_sect_kind)
- allocate AddrInfo::SectKind::objname dynamically
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14719
Basically:
CLG_(sprint_eventmapping) --> CLG_(eventmapping_as_string)
CLG_(sprint_mappingcost) --> CLG_(mappingcost_as_string)
The new functions return the string in a dynamically allocated buffer
that caller ought to free.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14699
Prepare print_file function to be converted to use VG_(fprintf).
Basically get rid of arithmetic involving the output buffer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14687
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
Change callgrind's init_cmdbuf function to allocate a large enough
buffer for the command line.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14597
r14271 Audit a few buffer sizes, increase one.
r14280 Audit buffer size.
r14296 Remove a few unneeded header files.
r14310 Replace fixed size buffers with a large enough buffers.
r14338 Remove a dead assignment in print_bbcs and make global variable
print_fd a local variable.
r14359 Remove a benign macro redefinition in cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14595
rev 14469 gives better description of the tweak done to the
simulated cache. Update filtering logic to filter this (variable) tweaking
msg.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14486
