Mark Wielaard [Wed, 17 Apr 2013 13:48:29 +0000 (13:48 +0000)]
Simplify read_unitinfo_dwarf2. Only try to read the first DIE.
Bug #305513. We should only read the first DIE of a compilation unit.
Each compilation unit header is followed by a single DW_TAG_compile_unit
(or DW_TAG_partial_unit, but those aren't important here) and its children.
There is no reason to read any of the children at this point. If the first
DIE isn't a DW_TAG_compile_unit we are done, none of the child DIEs will
provide any useful information.
Mark Wielaard [Thu, 11 Apr 2013 17:55:39 +0000 (17:55 +0000)]
read_unitinfo_dwarf2 DW_FORM_ref_addr is address size in DWARF version 2.
Bug #305513 contained a patch for some extra robustness checks. But
the real cause of crashing in the read_unitinfo_dwarf2 DWARF reader
seemed to have been this issue where DWARF version 2 DWZ partial_units
were read and DW_FORM_ref_addr had an unexpected size. This combination
is rare. DWARF version 4 is the current default version of GCC.
Implement ARM SDIV and UDIV instructions. Fixes #314178. Partially
based on a patch by Ben Cheng, bccheng@android.com. Also renames two
misnamed PPC helpers.
Solve false negative for various malloc replaced functions arguments
The replacement functions are running on the simulated CPU.
The code on the simulated CPU does not necessarily use
all arguments. E.g. args can be ignored and/or only given
to a NON SIMD call.
The definedness of such 'unused' arguments will not be verified
by memcheck.
A call to 'trigger_memcheck_error_if_undefined' allows
memcheck to detect such errors for the otherwise unused args.
Apart of allowing memcheck to detect an error, the function
trigger_memcheck_error_if_undefined has no effect and
has a minimal cost for other tools replacing malloc functions.
(suggestion of the 'no operation check' from Julian).
tested on f12/x86, debian6/amd64, f18/ppc64
Note that some Darwin specific code has been modified
in coregrind/m_replace_malloc/vg_replace_malloc.c.
(Some of) this code has not been compiled (no access to a
Darwin system). The code changed is trivial, so there is
some chance it will compile and even maybe work.
Added a new test verifying that various malloc related
functions undefined args are triggering an error in memcheck.
Petar Jovanovic [Thu, 4 Apr 2013 10:55:09 +0000 (10:55 +0000)]
mips: add different value for SOCK_STREAM
MIPS uses different values for socket types.
This is protected by ARCH_HAS_SOCKET_TYPES in Linux kernel and we introduce
it here too. This is important for log-socket feature, and it resolves the
issue reported in https://bugs.kde.org/show_bug.cgi?id=313267#c21.
Julian Seward [Wed, 27 Mar 2013 11:40:02 +0000 (11:40 +0000)]
Memcheck fixes for new IR ops introduced by r2702 (which added support
for AVX2, BMI1, BMI2 and FMA instructions). Part of #305728.
(Jakub Jelinek, jakub@redhat.com)
Carl Love [Wed, 20 Mar 2013 15:51:34 +0000 (15:51 +0000)]
VEX, ppc code cleanup
This patch removes some dead code left behind when the code was restructured
to fix the implementation changes to make it compliant with the iop
definitions.
The patch makes no functional changes as it is just removing code that is not
reachable.
This patch is for Bugzilla 314269.
Signed-off-by: Carl Love <cel@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/vex/trunk@2697
Better fix for 295590
(problem reported in bug 307082, comment 8).
Solution applied is similar to what is in 307082 patch
(i.e. do not destroy the internal helgrind var if nWaiters > 0).
But also do not remove it from the FM.
Document that user level client stack switches might cause crashes
and that these crahses might be avoided using VALGRIND_STACK_REGISTER
See bug 316613
Fix 316535 Use of |signed int| instead of (unsigned) |size_t| in messages...
* when SEGV trapped, report the main thread size as an unsigned size_t
* Similar for memcheck overlap errors
For example, for the 2 calls:
memcpy(&a, &a, 2147483648UL);
memcpy(&a, &a, -1); // silently accepted by gcc 4.4.4 -Wall
// while the 3rd arg is supposed to be a size_t
we now obtain (on a 32 bit system)
Source and destination overlap in memcpy(0xbe97113f, 0xbe97113f, 2147483648)
Source and destination overlap in memcpy(0xbef6d13f, 0xbef6d13f, 4294967295)
instead of
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -2147483648)
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -1)
Do not ask me why
memcpy(&a, &a, -1);
is supposed to be accepted/acceptable/valid code.
Julian Seward [Tue, 5 Mar 2013 10:35:44 +0000 (10:35 +0000)]
Handle "vmov qDest.I32 V128{0xFFFF}" so to speak, and make the case
for a zero immediate more similar. Verify assembled output against
GNU as. Fixes #311318.
Fix inconsistency between callgrind and format spec
Bug found by, and fix based on a patch by Mark Wielaard
Callgrind format specification was inconsistent with
what Callgrind generates, and what callgrind_annotate
accepted. Now, callgrind_annotate accepts the examples
in the format specification.
* Callgrind writes 'cfi=' lines for when a call target goes
into another source file. According to the spec, 'cfl=' is
used for this. Change the spec to allow both, and change
callgrind_annotate to accept both.
* The spec requires just an "events:" line as minimum header
to render the file as correct according to the specification.
callgrind_annotate also expected a 'cmd=' line. Fixed.
* The 'summary:' line is optional in the spec. Fixed in
callgrind_annotate. If not provided, summary is calculated
from all cost lines.
Better document an ignored return value.
The call to VG_(gdbserver_report_signal) is ignored
in synth_fault_common (m_signals.c) as these signals
are always to be delivered (as explained by the following
comment).
=> better document that the return value is ignored on purpose.
(spotted by Florian, using Coverity)
announce fix for 309823 Generate errors for still reachable blocks
Functionality is provided via the new 3.9.0 arg
--errors-for-leak-kinds=kind1,kind2,.. which leak kinds are errors?
[definite,possible]
where kind is one of definite indirect possible reachable all none
small changes in sendmsg.c regtest
* avoid a warning related to pointer types
* replace exit (0) by return 0 (might help backtraces on Darwin, suggestion by Rich Coe)
Petar Jovanovic [Wed, 27 Feb 2013 23:17:33 +0000 (23:17 +0000)]
mips: adding MIPS64LE support to Valgrind
Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
Petar Jovanovic [Wed, 27 Feb 2013 22:57:17 +0000 (22:57 +0000)]
mips: adding MIPS64LE support to VEX
Necessary changes to VEX to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
Fix vassert_fail producing random output for an empty format
vsnprintf does not do any addition to the buffer for an empty
format. So, buf was not null terminated.
This e.g. causes an assert_fail to output random characters
after the failed expression.
Fix by ensuring the buffer of vsnprintf is always null terminated
to start with.
Assertion
valgrind: m_transtab.c:674 (find_TTEntry_from_hcode):
Assertion '(UChar*)sec->tt[tteNo].tcptr <= (UChar*)hcode' failed.
failure (encountered on some platforms while running gdbsrv tests).
The problem is related to invalidated entries and the host_extents
mapping between hostcode and the translation table entry.
The problem: when an entry is invalidated, the translation table
entry is changed to status Deleted. However, the host extent array
element is not cleaned up.
If a search for a host code address (find_TTEntry_from_hcode)
finds this entry, the translation table entry in Deleted status
is considered as a 'not found', which ensures that the invalidated
entry is not used (e.g. for chaining).
This is all ok.
However, it might be that this Deleted entry is re-used
(see function VG_(add_to_transtab), searching for a Empty
or Deleted entry.
If the Deleted entry is re-used, then a search for the
dead host code can give a result pointing to the re-used
entry. That is clearly wrong.
Note that it is unclear if this bug can only be triggered
while using gdbsrv or if this bug can be triggered with
just the "normal" invalidation logic of translation.
gdbsrv being a heavy "user" of invalidation, it might
be it helps to trigger the code. Alternatively, as gdbsrv
invalidation is special (e.g. invalidation of some entries
is done during translation of other entries), it might be
the bug is specific to gdbsrv.
In any case, to avoid the bug:
searching for an host code address must not only
ignore Deleted entries, but must also ignore an entry
found via a host_extent element which is for a Deleted
entry that was re-used afterwards (pointed to by a
newer host_extent element).
Multiple solutions are possible for fixing the bug:
Sol1: cleanup the host_extents array when an entry is deleted.
The cleanup is however deemed costly:
Each invalidate operation must do a search in the host_extents.
The host_extents array must then be "compacted" to remove
the "dead" host extent element from the array.
The compact operation can be avoided if instead of removing
the element, one marks instead the element as "dead"
e.g. by using one bit of UInt len for that:
UInt len : 31;
Bool dead : 1;
This avoids the compact, but still incurrs the cost of
search and modify the host_extent for each entry invalidated.
Invalidating entries seems to be a critical operation
(e.g. specific ECLASS related data structures have been
done to allow fast deletion).
=> it is deemed that a solution not incurring cost during
invaliation is preferrable.
* Sol 2: detect in find_TTEntry_from_hcode
that the host_extent element is re-used, and handle it similarly
to an host_extents which points at a Deleted entry.
This detection is possible as if an entry is re-used after
having been deleted, this implies that its host code will be
after the end of the host code of the deleted entry
(as host code of a sector is not re-used).
The attached patch implements this solution.
* Sol 3: avoid re-using an entry : the entry would then stay
in Deleted state. This is deemed not ok as it would
imply that invalidation of entries will cause a sector to
become full faster.
The patch:
* adds a new function
Bool HostExtent__is_dead (const HostExtent* hx, const Sector* sec)
telling if the host extent hx from sector sec is a dead entry.
* this function is used in find_TTEntry_from_hcode so that
dead host extents are not resulting in host code to be found.
* adds a regression test which caused the assert failure before
(bug was found/reported/isolated in a small test case by Dejan Jevtic).
* To check the logic of HostExtent__is_dead, m_transtab.c sanity check is
completed to verify that the nr of entries in use in a sector is equal
to the nr of non dead entries in the host extent array.
* adds/improves traces in m_transtab.c (enabled at compile
time using #define DEBUG_TRANSTAB).
Some already existing 'if (0)' conditions are replaced
by if (DEBUG_TRANSTAB)
Regression tested on
f12/x86
debian6/amd64 (also with export EXTRA_REGTEST_OPTS=--sanity-level=4)
projects / thirdparty / valgrind.git / log
