On these platforms, implement read_/write_<type> by doing a direct
access, rather than calling a function that will read or write
'byte per byte'.
For platforms that do not have efficient unaligned access,
or that do not support at all unaligned access, call function
readUAS_/writeUAS_<type> that works as before.
Currently, direct acecss is activated only for x86 and amd64.
Unclear what other platforms support (efficiently) unaligned access.
On unwind intensive code (such as perf/memrw on amd64), this patch
gives up to 5% improvement.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15290
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
Tool files shall use tl_assert not vg_assert.
Fix code accordingly.
Adapted check_headers_and_includes to make sure the code
stays clean in that respect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14542
only decrease the size of a block, does not change the address,
does not need to alloc another block and copy the memory,
and (if big enough) makes the excess memory available for other
allocations.
VG_(arena_realloc_shrink) is then used for debuginfo storage.c
(replacing an allocation + copy).
Also use it in the dedup pool, to recuperate the unused
memory of the last pool.
This also allows to re-increase the string pool size to the original
3.9.0 value of 64Kb. All this slightly decrease the peak and in use
memory of dinfo.
VG_(arena_realloc_shrink) will also be used to implement (in another patch)
a dedup pool which "numbers" the allocated elements.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14122
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
