We can have stacktraces such as:
==41840== by 0x10000927: a1 (deep.c:27)
==41840== by 0x1000096F: main (deep.c:35)
==41840== by 0x4126BEB: generic_start_main.isra.0 (in /usr/lib64/libc-2.17.so)
==41840== by 0x4126E13: __libc_start_main (in /usr/lib64/libc-2.17.so)
So, add generic_start_main.isra.0 as a below main function.
This fixes the test massif/tests/deep-D
The code handling array bounds is not ready to accept a reference
to something else (not very clear what this reference could be) :
the code only expects directly the value of a bound.
So, it was using the reference (i.e. an offset somewehere in the debug
info) as the value of the bound.
This then gave huge bounds for some arrays, causing an overlap
in the stack variable handling code in exp-sgcheck.
Such references seems to be used sometimes for arrays with variable
size stack allocated.
Fix (or rather bypass) the problem by not considering that we have
a usable array bound when a reference is given.
* produce (more) user messages when valgrind cannot read a pdb file.
* recover properly from an invalid/unsupported pdb file.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16465
This makes reading of compressed debuginfo usable for very large object files.
It also adds a bunch extra documentation about a tricky invariant in the
compressed debuginfo handling (a recursive cache refill path!) and adds a
whole bunch of assertions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16279
* sym name cache to cache the 'isText' characteristic of the cached sym_name
* implement the match anywhere also in the cache
Not handling matchAnywhere has bad performance effect on callgrind, as almost many
IPs were considered as a fn entry, while they were not.
* use the same convention to name the findText argument
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16136
Support work for xtree: as xtree implementation makes a high
nr of calls to get_sym_name, this cache improves the performance
as usually, stacktraces are repeatitively querying the same
addresses.
The cache follows the same principle as the cfsi_m_cache.
In particular, cache is cleared together with the cfsi_m cache.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16121
SUNWDTRACE program header. Newer Solaris no longer utilizes
this program header as a scratchspace for DTrace fasttrap
provider, before libc is loaded.
For the time being, it serves as a space for initial thread
pointer.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15936
for Elf{32,64}_Chdr. This is fallout from r15868. That commit provided
a configure test, but the resulting config.h was not included here, causing
the test results to be ignored.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15869
- zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
- zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)
Patch by: Aleksandar Rikalo <aleksandar.rikalo@imgtec.com>
Fixes BZ#303877
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15868
is no longer needed. The situation with multiple ".rodata" sections existed
only between dozens of builds of Solaris 12.
Fixes BZ#360749
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15853
* Complain instead of asserting when negative line nr in inline info
* use a macro to factorise the complain once logic about lineno limits
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15780
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
Line numbers should correctly reflect all instructions belonging to a source line,
regardless of is_stmt value. Previously only instructions covered by
'is_stmt = 1' were attributed to a source line.
Fixes BZ#356044
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15741
This implements the interception of all globally public allocation
functions by default. It works by adding a flag to the spec to say the
interception only applies to global functions. Which is set for the
somalloc spec. The librarypath to match is set to "*" unless the user
overrides it. Then each DiSym keeps track of whether the symbol is local
or global. For a spec which has isGlobal set only isGlobal symbols will
match.
Note that because of padding to keep the addresses in DiSym aligned the
addition of the extra bool isGlobal doesn't actually grow the struct.
The comments explain how the struct could be made more compact on 32bit
systems, but this isn't as easy on 64bit systems. So I didn't try to do
that in this patch.
For ELF symbols keeping track of which are global is trivial. For pdb I
had to guess and made only the "Public" symbols global. I don't know
how/if macho keeps track of global symbols or not. For now I just mark
all of them local (which just means things work as previously on platforms
that use machos, no non-system symbols are matches by default for somalloc
unless the user explicitly tells which library name to match).
Included are two testcases for shared libraries (wrapmalloc) and staticly
linked (wrapmallocstatic) malloc/free overrides that depend on the new
default. One existing testcase (new_override) was adjusted to explicitly
not use the new somalloc default because it depends on a user defined
new implementation that has side-effects and should explicitly not be
intercepted.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15726
The ELF debug info reader on Solaris now performs a quick pre-scan of section
headers for .rodata sections. If there are multiple .rodata sections
present then symbols from .symtab are scanned which section they point to.
The "true" .rodata section is thus determined.
Fixes BZ#353802.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15719
hardwired absolute path names. People can always arrange $PATH
such that these tools are found.
Fixes BZ #294065. Patch by Austin English <austinenglish@gmail.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15652
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
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
evaluation starts. For DW_CFA_val_expression and DW_CFA_expression
doing so is correct, but not for DW_CFA_def_cfa_expression.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15160
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
code. Previously functions exceeding that size were observed in the
field. Assert for 100x that amount.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14997
