Julian Seward [Mon, 14 Oct 2013 14:09:35 +0000 (14:09 +0000)]
Update expected output following r13642, which fixes #323432
(When calling pthread_cond_destroy or pthread_mutex_destroy
with initializers as argument Helgrind (incorrectly)
reports errors.)
This introduces a new race report (but no new race) in
some conditions. I think this is OK because the race only
occurs in the case where the program is buggy (racey) anyway.
Julian Seward [Mon, 14 Oct 2013 13:51:25 +0000 (13:51 +0000)]
Fix #323432: When calling pthread_cond_destroy or pthread_mutex_destroy
with initializers as argument Helgrind (incorrectly) reports errors.
(Peter Boström, valgrind@pbos.me)
Julian Seward [Mon, 14 Oct 2013 12:13:52 +0000 (12:13 +0000)]
For pthread_cond_destroy, don't report a false it's-still-waited-on
error if in fact the last wait finished with ETIMEDOUT.
Fixes #324149. (Peter Boström, valgrind@pbos.me)
Fix use of uninit heuristic set for monitor command
* initialise leak_check heuristic parameter in the leak_check monitor command
* show the default value (none heuristic) in the monitor help command
(none value chosen as default as this gives a backward compatible
behaviour).
* document the heuristic leak check parameter in memcheck manual
monitor command section
Carl Love [Wed, 9 Oct 2013 17:56:34 +0000 (17:56 +0000)]
Power PC, add the two privileged Transactional Memory instructions.
The initial Transactional Memory instruction patch did not include the two
privileged (OS) instructions treclaim and trechkpt. VEX commit 2784 added
the support for these two instructions.
This patch adds a touch test to make sure all of the POWER Transactional
memory instrutions are recognized by Valgrind. All of the the Transactional
Memory instructions, with the exception of tbegin, are treated as NOPs in the
first implementation. The tbegin instruction causes the transaction to fail
thus no additional Transactional Memory instructions on the successful
transaction path would be executed in a real program. This test just makes
sure each instruction is actually recognized by Valgrind.
Fix leak scan SEGV catcher when ptr starts in unreadable page (readable for aspacemgr)
The fault catcher installed during leak scan to catter e.g. for
possible desynchronisation between real protection and aspacemgr
was not activated when the scanned ptr was directly pointing in
a desynchronised page.
This was (initially only) visible on ppc32 (gcc110) as the page size of
gcc110 is big (64 K).
=> modified the leak-segv-jmp test so as to produce the problem also
on systems with smaller pages.
The fix consists in calling the setjmp before the scan loop,
and skip the bad address which has been recorded by the fault
catcher.
Also, deemed better to just skip one single Addr rather than a full page
(e.g. to skip less data in case some addresses are unreadable e.g.
on strange hardware).
Performance of the leak scan has been measured, seems slightly
faster on x86,amd64 and ppc32. Slightly slower on ppc64.
Also if verbose argument is given, outputs the nr of bytes skipped
due to fault.
* Remove dead code in m_oset.c VG_(OSetGen_ResetIterAt)
The code at the end of VG_(OSetGen_ResetIterAt) was unreachable
(detected by BEAM checker).
Looking at SVN, the initial commit of VG_(OSetGen_ResetIterAt)
already contained this deadcode.
* pub_tool_oset.h was wrongly indicating that signed words could
be used for fast cmp oset.
* modified memcheck/tests/unit_oset.c to test VG_(OSetGen_ResetIterAt)
* modified memcheck/tests/unit_oset.c to not use signed words
(it was previously using signed words, but only with positive values)
Florian Krohm [Fri, 4 Oct 2013 21:13:16 +0000 (21:13 +0000)]
Disable drd/tests/std_thread.cpp for clang.
clang 3.3 produces an error message for /usr/include/c++/4.6/chrono
which happens to get included somewhere inside <thread>.
This happens with C++ headers from:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3.
Florian Krohm [Fri, 4 Oct 2013 21:12:17 +0000 (21:12 +0000)]
Adjust CFLAGS and CXXFLAGS for compilation with clang. The current
setting suppresses almost all warnings originating in source code
constructs. It does ot yet suppress warnings from unrecognised command
line flags as they may be the reason for regression test failures
which have not yet been investigated.
Florian Krohm [Fri, 4 Oct 2013 11:35:50 +0000 (11:35 +0000)]
Add a few feature tests to configure.ac because clang does not
understand the following:
- nested functions
- -gstabs option
- loopnel instruction
- addr32 in asm statements
- 'p' constraint in asm statements
Florian Krohm [Fri, 4 Oct 2013 11:29:26 +0000 (11:29 +0000)]
Remove 4 tests of the pextrw instruction.
Those tests were rejected by clang and according to the
analysis below by Tom Hughes do not add anything new.
Analysis:
I'm not 100% sure that clang is right though - the Intel manual
clearly describes that argument as "reg" rather than "r32" which
is why I will have included the 64 bit version in the test. It also says:
"The upper bits of r32 or r64 is zeroed."
and:
"If the destination operand is a general-purpose register, the
default operand size is 64-bits in 64-bit mode."
which basically means that REX.W is implied for this op and there is
no way to encode a 32 bit version when running in 64 bit mode.
So in principle you could encode it as:
44 0f c5 ce 00 pextrw $0x0,%mm6,%r9d
or:
4c 0f c5 ce 00 pextrw $0x0,%mm6,%r9
but in fact gcc assembles both versions to the first form.
Equally you could argue that as REX.W is implied both versions
should disassemble as %r9.
So I think clang is being overly picky, and if it was only going to
accept one version I would argue it should be %r9 not %r9d!
In practical terms dropping the second set of tests doesn't lose us anything though.
Fix compilation problem of memcheck/tests/leak-segv-jmp on ppc32
With the change, the test compiles on ppc32.
However, the test fails miserably with
Segmentation fault
while the whole purpose of the test was to see the leak search
would *not* segfault.
More investigations needed, but still committing as is to let
the tests compile and run.
Carl Love [Thu, 3 Oct 2013 21:43:10 +0000 (21:43 +0000)]
Phase 4 support for IBM Power ISA 2.07
This patch adds testcases for the following instructions added
in phase 4. The instructions are for doing various arithmetic,
logic, and load/store VSX operations:
Florian Krohm [Thu, 3 Oct 2013 20:54:52 +0000 (20:54 +0000)]
Change some inline assembler so it is no longer rejected by clang
as suggested by John Reiser and Greg Parker.
It seems that GCC has a more relaxed attitude about what it accepts
as valid input.
Carl Love [Wed, 2 Oct 2013 17:48:48 +0000 (17:48 +0000)]
The test case for the Transaction Memory instructions failes with older
compilers as the -mhtm flag is not known. The patch fixes the makefile
issue and addes #defines to the testcase code.
The testcase was added in valgrind commit 13607.
The bugzilla for adding the TM instruction support is 323803
Carl Love [Wed, 2 Oct 2013 16:28:57 +0000 (16:28 +0000)]
IBM POWER PC, Add the Transactional Memory test case
The test case for the transaction memory instructions executes the
failure path when run under valgrind. This is since the initial
Transaction Memory implemnetation is to simply fail the TBEGIN instruction
forcing the execution flow to take the failure path. When the
test case is executed on the real hardware, the success path will
be taken. Only the TBEGIN instruction actually does anything. All other
transactional memory instructions are NOPs since only failure path is executed
and it assumed to not have any transactional memory instructions on it.
Signed-off-by: Carl Love <cel@us.ibm.com>
VEX commit revision 2780
Bugzilla 323803
Carl Love [Tue, 1 Oct 2013 15:50:09 +0000 (15:50 +0000)]
Add tests for the phase 3 ISA 2.07 code patch
This patch adds testcases to an existing testcase
source file to test the new instructions which were
added to VEX support in the phase 3 ISA 2.07 code patch.
The patch also makes a small change to memcheck's
vbit tester code to allow successful execution.
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Bugzilla 324894. Corresponding VEX commit 2779
Dejan Jevtic [Tue, 1 Oct 2013 10:34:54 +0000 (10:34 +0000)]
mips32: Fix the align problem with mmap.
Valgrind is doing mmap always with MAP_FIXED. On mips32 we need to check arg4.
If the arg4 is MAP_SHARED we need to align the address to SHMLBA.
If the program tries to do mmap with VKI_FIXED Valgrind doesn't need to align
the address to SHMLBA.
Use global vars to point at possibly leaked
Depending on the compiler or optimisation level, the blocks that
are supposed to be possibly leaked are still reachable.
=> change the pointers to be global variables,
and do the allocation in a function, not in main.
add heuristics decreasing false possible "possible leaks" in c++ code.
The option --leak-check-heuristics=heur1,heur2,... can activate
various heuristics to decrease the number of false positive
"possible leaks" for C++ code. The available heuristics are
detecting valid interior pointers to std::stdstring, to new[] allocated
arrays with elements having destructors and to interior pointers pointing
to an inner part of a C++ object using multiple inheritance.
This fixes 280271 Valgrind reports possible memory leaks on still-reachable
std::string
This has been tested on x86/amd64/ppc32/ppc64.
First performance measurements seems to show a neglectible impact on
the leak search.
More feedback welcome both on performance and functional aspects
(false positive 'possibly leaked' rate decrease and/or
false negative 'possibly leaked' rate increase).
Note that the heuristic is not checking that the memory has been
allocated with "new" or "new[]", as it is expected that in some cases,
specific alloc fn are used for c++ objects instead of the standard new/new[].
If needed, we might add an option to check the alloc functions
to be new/new[].
In an attempt to fix the accounting for dynamic memory allocation
it turned out that coregrind freely allocates memory on the tool
arena (which it should not, conceptually) and tools rely on coregrind
doing so (by VG_(free)'ing memory allocated by coregrind).
Entangling this mess is risky and provides little benefit except
architectural cleanliness.
Thinking more about it... It isn't really all that interesting how
much memory is allocated by tool code in and by itself. What is
interesting is the total memory impact a tool has, e.g. as compared
to running "none".
So in this patch the number of memory arenas is consolidated by
subsuming VG_AR_TOOL/ERRORS/EXECCTXT into VG_AR_CORE.
VG_(malloc) and friends have been modified to operate on VG_AR_CORE.
Add a script 'check_headers_and_includes' to check that #include directives
are not against the grain.
Wrap this script together with 'check_makefile_consistency' into
'post_regtest_checks' and invoke that from the toplevel Makefile. So we can
easily add new checkers in the future.
Add a new make target 'post-regtest-checks' to just run those checks
and nothing else.
Double the size of the (already huge) translation cache on all
non-phone/tablet targets. The previous apparently-huge sizing is
evidently not huge enough for recent apps, eg, recent Firefox requires
circa 350k translations to get started and almost fills an 8-sector
cache merely starting up and then idling.
On Android targets, fall back to 6 sectors; space is critical.
Carl Love [Wed, 18 Sep 2013 16:06:46 +0000 (16:06 +0000)]
The patch fixes the assembly of the Power dcbtst and dcbt instructions.
The assembly of these instructions is not alwasy being done correctly as
described in the following email reply.
Re: Assembling Power instructions: dcbtst/dcbt.
From: Peter Bergner <bergner at vnet dot ibm dot com>
To: Paralkar Anmol-B07584 <B07584 at freescale dot com> Cc: "amodra at bigpond dot net dot au" <amodra at bigpond dot net dot au>, "binutils at sourceware dot org" <binutils at sourceware dot org>
Date: Fri, 13 Sep 2013 15:22:35 -0500
Subject: Re: Assembling Power instructions: dcbtst/dcbt.
Authentication-results: sourceware.org; auth=none
References: <DC6D7B34688246489A6578981A5ADEB9302A07 at 039-SN2MPN1-012 dot 039d dot mgd dot msft dot net>
On Fri, 2013-09-13 at 18:32 +0000, Paralkar Anmol-B07584 wrote:
> Hello,
>
> Per Power ISA Version 2.07 (May 3, 2013) "4.3.2 Data Cache Instructions",
> the assembly language syntax for the dcbtst instruction (pp. 771) is:
>
> dcbtst RA,RB,TH [Category: Server]
> dcbtst TH,RA,RB [Category: Embedded]
>
> and it's layout in the object code is:
>
> +------+------+------+------+------------+---+
> | 31 | TH | RA | RB | 246(0xF6) | / |
> |0 |6 |11 |16 |21 |31 |
> +------+------+------+------+------------+---+
>
> (Analogously: dcbt pp. 770)
>
> However, GAS (as of version 2.23.52.20130912) decides on the syntax to use based on
> processor/architecture dialect (not Power ISA Category), using the Server syntax in
> the case of POWER4 and the Embedded syntax for generic PPC or VLE.
> Consequently (e.g.),
>
> dcbtst 17, 14, 6
>
> in the assembly file gets "misassembled" under -many for a user-space program on Linux:
When you only specify -many (and not one of -mpower4, -mpower5, etc.),
the assembler/disassembler will choose a default -m<CPU> value for
you. That has changed over time, but is generally one of the newer
server cpus. For example, for binutils trunk, the default is now
-mpower8 and for your 2.23.x binutils, it is -mpower7.
That should force the assembler and disassembler to assemble
the instruction using the server operand order you want, but the bug
above (which is in 2.23) basically resets it to an old cpu, so it
chooses to use the embedded/old cpu setting.
The patch from Amodra fixes the issue by manually generating the correct
hex value for the instruction rather then leaving it to the assembler to
generate the hex value from the symbolic assembly instruction name.
Change the existing tests to print the value of the FCSR
register after the mips fpu instruction is executed.
Add tests that are testing the value of FCSR register.
Followup to r13553 which caused some build failures.
(1) Detect availability of pthread_setname_np. Ignore testcases
memcheck/tests/threadname[_xml] if not available.
(2) Enable _GNU_SOURCE to avold compiler warnings.
(3) In threadname_xml filter out stackframes referring to system
libraries. Added tests/filter_xml_frames to do that.
(4) Adjust .exp files as needed
(5) Do not ship stdout.exp for memcheck/tests/threadname[_xml].
Intercept prctl(PR_SET_NAME, name) and store the thread name so it
can be used in error messages. That should be helpful when debugging
multithreaded applications.
Patch by Matthias Schwarzott <zzam@gentoo.org> with some minor
modifications. Fixes BZ 322254.
Petar Jovanovic [Sun, 15 Sep 2013 22:49:01 +0000 (22:49 +0000)]
mips32/mips64: rename mips32_features to mips_features
As this file is now detecting mips64/Cavium boards, we are renaming it to
reflect that. The functional change is that mips_features now can detect
Cavium board and allow Cavium-specific tests to be run.
Fix inclusion of header files in coregrind. No pub_tool_*.h should be
included here.
Added pub_core_poolalloc.h and renamed pub_tool_inner.h to pub_core_inner.h.
projects / thirdparty / valgrind.git / log
