Use seg->start instead of a as DebugInfoMapping avma. Normally seg->start
equals a. But when it is not then the size of the map might extend beyond
the segment (and not actually cover the start of the segment). When another
ELF file is them mapped right after this then it triggers an overlap purge
of the DebugInfo. In the case the mapping was for libc or ld.so this then
removes all intercepts causing "bad things".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15398
e.g. perf/memrw is improved by 2% to 3% with this patch.
The unwinding code on x86 is trying to unwind using
either the %ebp-chain or CFI unwinding.
If these 2 techniques fail, then it tries to unwind
using FPO (PDB) debug info.
However, unless running wine or similar, there will never be
such FPO/PDB info.
The function VG_(use_FPO_info) is thus called for nothing
for each 'end of stack'. This function scans all the loaded di
to find a debug info that has some FP, to not find anything.
With this patch, the unwind code on x86 will only call VG_(use_FPO_info) if
some FPO/PDB info was loaded.
The fact that FPO/PDB info was loaded is cached and updated similarly to
cfi cache : each time new debug info is loaded, the cache value is refreshed
using the debuginfo generation.
The patch also changes the name of VG_(CF_info_generation)
to VG_(debuginfo_generation), as this generation is changed for
any kind of load or unload of debug info, not only for CFI based debug
info
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15293
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
(1) In r14664 VG_(get_fnname_if_entry) was changed to always
return a function name, even if that function was *not* an
entry. That broke callgrind and was also confusing because
it contradicts what "get_fnname_if_entry" suggests.
(2) In r14189 a function call was removed because it was considered
redundant which it was not.
Both bugs were hunted down by Joseph Weidendorfer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15003
address space manager. Callers should neither modify the string nor
free it (as the string resides is statically allocated memory). That
calls for a const HChar *
The type change exposed two bugs. One in m_addrinfo.c and one in
m_debuginfo.c. In both cases the returned string could possibly be freed later
on. So we need to strdup it first. Now fixed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14886
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
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
In the non-XML part buf_dirname was read without observing the
know_dirinfo guard. Now fixed. Initialise buf_dirname nevertheless.
Also remove a dead assignment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14707
Changes VG_(describe_IP) to return the untruncated result in a statically
allocated local buffer. Fix call sites and update two .exp files who had
truncated names.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14685
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
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
that once an element has been allocated and added to the pool it must
not be modified afterwards. See the documentation in pub_tool_deduppoolalloc.h
The rest of the patch is ripple.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14654
truncate overlaps in the DebugInfoMappings that have been collected by
the DebugInfo's FSM. Not doing so can confuse ML_(read_elf_debug_info)'s
computation of bias values. Observed to be a problem when reading EDIDX
sections for objects mangled by Mike Hommey's elfhack program.
See http://bugzilla.mozilla.org/show_bug.cgi?id=788974
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14632
Change VG_(resolve_filename) to not truncate the result which is returned
in a static buffer now. Fix callsites.
Simplify VG_(di_notify_pdb_debuginfo) to use VG_(resolve_filename).
Fix VG_(readlink) prototype.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14628
This change makes VG_(clo_suppressions), VG_(clo_fullpath_after),
and VG_(clo_req_tsyms) XArrays. They used to be arrays of fixed size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14609
Since valgrind 3.9.0 the STABS support was already disabled completely.
But the code was still there being compiled and we were still searching
for stabs sections in binaries. Completely remove all sources, tests and
references. Add a note to coregrind/m_debuginfo/README.txt to mention
the old code can be found in the subversion repository.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14550
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
readdwarf3 would only look for alt dwz files using the build-id.
But alt files can be installed relative to the debug (or main) file.
Fix find_debug_file to allow searching of relative files even if
we don't want an ET_REL (rel_ok) file, and pass the build-id to
open_debug_file so it can be checked. Add the debug file path to
_DebugInfoFSM and set it in find_debug_file once opened. Pass the
dbgname or filename as relative file to resolve an altfile in
read_elf_debug_info when we ahava an debugaltlink_escn.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14464
(used for ppc64 platforms) #ifdef-ed and accessed by macros
that becomes NOP on non ppc64 platforms.
This decreases the debuginfo memory by about 2.5 Mb on a big 32 bit application.
Note : doing that, some questions were encountered in the way
tocptr and local_ep have (or do not have) to be copied/maintained
in storage.c canonicaliseSymtab
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14273
files in the dwarf3 reader.
Basically, the change consists in replacing in the DiInlLoc struct
const HChar* filename; /* caller source filename */
by
UInt fndn_ix; /* index in di->fndnpool of caller source
dirname/filename */
A similar change is done in DiVariable struct, as the
read_filename_Table code is shared between the inline info reader
and the varinfo reader.
Note however that outputting dirname in variable description
is not done. Unclear if that is desired or not.
It should be trivially doable however.
Replacing filename by fndn_ix implies a bunch of semi-mechanical
changes.
The code to read the directory names is in the new function
static
XArray* read_dirname_xa (struct _DebugInfo* di, const HChar *compdir,
Cursor *c,
Bool td3 )
Note that readdwarf.c and readdwarf3.c have significant duplicated
logic. Would be nice to integrate these 2 dwarf readers in one
single reader. This function is directly inspired from
an equivalent piece of code in readdwarf.c.
Modified memcheck/tests/varinfo5.vgtest to test the dirname appears
in the inlined functions.
Impact on memory is neglectable (a few Kb on a big executable).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14245
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334836.
POWER PC, add the functional Little Endian support, patch 2
The IBM POWER processor now supports both Big Endian and Little Endian.
The ABI for Little Endian also changes. Specifically, the function
descriptor is not used, the stack size changed, accessing the TOC
changed. Functions now have a local and a global entry point. Register
r2 contains the TOC for local calls and register r12 contains the TOC
for global calls. This patch makes the functional changes to the
Valgrind tool. The patch makes the changes needed for the
none/tests/ppc32 and none/tests/ppc64 Makefile.am. A number of the
ppc specific tests have Endian dependencies that are not fixed in
this patch. They are fixed in the next patch.
Per Julian's comments renamed coregrind/m_dispatch/dispatch-ppc64-linux.S
to coregrind/m_dispatch/dispatch-ppc64be-linux.S Created new file for LE
coregrind/m_dispatch/dispatch-ppc64le-linux.S. The same was done for
coregrind/m_syswrap/syscall-ppc-linux.S.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14239
to add PPC64 LE support. The other two patches can be found in Bugzillas
334834 and 334836. The commit does not have a VEX commit associated with it.
POWER PC, add initial Little Endian support
The IBM POWER processor now supports both Big Endian and Little Endian.
This patch renames the #defines with the name ppc64 to ppc64be for the BE
specific code. This patch adds the Little Endian #define ppc64le to the
Additionally, a few functions are renamed to remove BE from the name if the
function is used by BE and LE. Functions that are BE specific have BE put
in the name.
The goals of this patch is to make sure #defines, function names and
variables consistently use PPC64/ppc64 if it refers to BE and LE,
PPC64BE/ppc64be if it is specific to BE, PPC64LE/ppc64le if it is LE
specific. The patch does not break the code for PPC64 Big Endian.
The test files memcheck/tests/atomic_incs.c, tests/power_insn_available.c
and tests/power_insn_available.c are also updated to the new #define
definition for PPC64 BE.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14238
On a big executable, the trunk needs:
dinfo: 134873088/71438336 max/curr mmap'd, 134607808/66717872 max/curr
With the patch, we have:
dinfo: 99065856/56836096 max/curr mmap'd, 97883776/51663656 max/curr
So, peak dinfo memory decreases by about 36Mb, and final by 15Mb.
(for info, valgrind 3.9.0 uses
dinfo: 158941184/109666304 max/curr mmap'd, 156775944/107590656 max/curr
So, compared to 3.9.0, dinfo peak decreases by about 40%, and the final
memory is divided by more than 2).
The memory decrease is obtained by:
* using a dedup pool to store filename/dirname pair for the loctab source/line
information.
As typically, there is not a lot of such pairs, typically a UShort is
good enough to identify a fn/dn pair in a dedup pool.
To avoid losing memory due to alignment, the fndn indexes are stored
in a "parallel" array to the DiLoc loctab array, with entries having
1, or 2 or 4 bytes according to the nr of fn/dn pairs in the dedup pool.
See priv_storage.h comments for details.
(there was a extensible WordArray local implementation in readdwarf.c.
As with this change, we use an xarray, the local implementation was
removed).
* the memory needed for --read-inline-info is slightly decreased (-2Mb)
by removing the (unused) dirname from the DiInlLoc struct.
Handling dirname for inlined function caller implies to rework
the dwarf3 parser read_filename_table common to the var and inlinfo parser.
Waiting for this to be done, the dirname component is removed from DiInlLoc.
* the stabs reader (readstabs.c) is broken since 3.9.0.
For this change, the code has been updated to make it compile with the new
DiLoc/FnDn dedup pool. As the code is completely broken, a vg_assert(0)
has been put at the begin of the stabs reader.
* the pdb reader (readpdb.c) has been trivially updated and should still work.
It has not been tested (how do we test this ?).
A follow-up patch will be done to avoid doing too many calls to
ML_(addFnDn) : instead of having one call per ML_(addLineInfo), one
should have a single call done when reading the filename table.
This has also be tested in an outer/inner setup, to verify no
memory leak/bugs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14158
* Avoid printing the size of a null dedup pool
* Avoid warnings of 2 unused variables on some platforms
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14132
On a big executable, the trunk needs:
dinfo: 155844608/106737664 max/curr mmap'd 155572624/102276760 max/curr
With the patch, we have:
dinfo: 134873088/70389760 max/curr mmap'd 134607808/66717512 max/curr
So, peak dinfo memory decreases by 21Mb, and final by 36Mb.
The memory decrease is obtained by:
* using a dedup pool to store the machine dependent part (cfsi_m)
of the cfsi information as this information is highly duplicated.
For x86 and arm64, the duplication factor of cfsi machine dependent
part is very high (up to a factor 60).
For arm64, it is more like a factor 3.
A 'variable size' (1, 2 or 4 bytes) is automatically used to identify
the cfsi_m, if there is less than or more than 255/64K different cfsi_m.
* not storing explicitely the length of a range for which a cfsi_m
is to be used: in a large majority of the cases, ranges are
consecutive, and so the end of a range is just one byte before
the start of the next range.
So, we do not store the length of the ranges.
If there is a hole between 2 ranges, the hole is stored explicitely
as a range in which we have no cfsi_m information.
On x86 and amd64, we have quite some holes (something like one hole
every 7 cfsi). On arm64, we have very few holes (less than one hole
every 50 cfsi).
Even with the nr of holes on x86/amd64, it is more memory efficient
to store the holes rather than to store the length of each cfsi.
* Merging consecutive ranges that have the same cfsi_m info:
Many cfsi are "mergeable": there is no hole between 2 cfsi, and their
machine dependent part is identical
(I guess the unwind info needed by valgrind is subset of the full
unwind info, and so, the cfsi entries are not merged by the compiler,
but can be merged for simple unwind). Depending on the platform
(x86, amd64, arm64) and of the library/object file, we can have a
significant nr of mergeable entries.
The patch is not very small, but a lot is mechanical changes.
The patch has been compiled and tested on x86/amd64/ppc32/ppc64
(but ppc does not use cfsi so that just verifies it compiles).
It has been compiled on arm64, and "tested" by launching valgrind on
one executable.
It has not been compiled on s390 and mips.
With some luck, maybe it will compile on these platforms.
And if that uses the whole provision of luck for 2014, it might even work
on these platforms :).
If it does not compile, the fix should be straightforward.
Runtime problems might be more tricky (but arm64 "worked out of the box"
once x86/amd64 were ok).
This has also be tested in an outer/inner setup, to verify no memory leak/bugs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14129
