Add mips64-le implementation of:
- atomic_add_8bit
- atomic_add_16bit
- atomic_add_32bit
- atomic_add_64bit
- do_acasW
Minor fixes for mips32 implementations are included as well.
These functions are needed to execute atomic_incs and annotate_hbefore
tests on mips64le.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13357
(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.
+ add a test case (re-using the drd test case)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13329
In case a lock order violation is detected in a multi lock cycle,
then the current code cannot produce the set of locks and the
stack traces involved in the cycle.
However, it is still possible to produce the stack trace of
the new lock and the other lock between which a cycle was discovered.
Also, add a comment in the code clarifying why the set of locks
establishing the required order cannot (currently) be produced.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13281
This patch changes the way static variables are
recorded by readdwarf3.c (when giving --read-var-info=yes),
improving the way such variables are described.
Currently:
A static variable does not have the DW_AT_external tag.
So, readdwarf3.c does not consider it a global variable.
It is rather considered a "local" variable.
When it is recorded, it is associated to a range of program counters
(the functions in the file where it is visible).
However, even if the static variable is only visible
in the source file where it is declared, it can in reality
be used by any range of program counters, typically
by having the address of the local variable passed
to other functions.
Such local variable can then only be described
when the program counter is in the range of program
counters for which it has been recorded.
However, this (local) description is obtained
by a kludge in debuginfo.c (around line 3285).
This kludge then produces a strange description,
telling that the variable has been declared in
frame 0 of a thread (see second example below).
The kludge is not always able to describe
the address (if the IP of the tid is in another file than
where the variable has been declared).
I suspect the kludge can sometimes describe the var as being
declared in an unrelated thread
(e.g. if an error is triggered by tid 5, but tid1 is by
luck in an IP corresponding to the recorded range).
The patch changes the way a static variable is recorded:
if DW_AT_external tag is found, a variable is marked as global.
If a variable is not external, but is seen when level is 1,
then we record the variable as a global variable (i.e.
with a full IP range).
This improves the way such static variable are described:
* they are described even if being accessed by other files.
* their description is not in an artificial "thread frame".
First example:
**************
a variable cannot be described because it is
accessed by a function in another file:
with the trunk:
==20410== ----------------------------------------------------------------
==20410==
==20410== Possible data race during read of size 4 at 0x600F54 by thread #1
==20410== Locks held: none
==20410== at 0x4007E4: a (abc.c:42)
==20410== by 0x4006BC: main (mabc.c:24)
==20410==
==20410== This conflicts with a previous write of size 4 by thread #2
==20410== Locks held: none
==20410== at 0x4007ED: a (abc.c:42)
==20410== by 0x400651: brussels_fn (mabc.c:9)
==20410== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==20410== by 0x4E348C9: start_thread (pthread_create.c:300)
==20410==
==20410== ----------------------------------------------------------------
with the patch:
==4515== ----------------------------------------------------------------
==4515==
==4515== Possible data race during read of size 4 at 0x600F54 by thread #1
==4515== Locks held: none
==4515== at 0x4007E4: a (abc.c:42)
==4515== by 0x4006BC: main (mabc.c:24)
==4515==
==4515== This conflicts with a previous write of size 4 by thread #2
==4515== Locks held: none
==4515== at 0x4007ED: a (abc.c:42)
==4515== by 0x400651: brussels_fn (mabc.c:9)
==4515== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==4515== by 0x4E348C9: start_thread (pthread_create.c:300)
==4515==
==4515== Location 0x600f54 is 0 bytes inside global var "static_global"
==4515== declared at mabc.c:4
==4515==
==4515== ----------------------------------------------------------------
Second example:
***************
When the kludge can describe the variable, it is strangely described
as being declared in a frame of a thread, while for sure the declaration
has nothing to do with a thread
With the trunk:
==20410== Location 0x600f68 is 0 bytes inside local var "static_global_a"
==20410== declared at abc.c:3, in frame #0 of thread 1
With the patch:
==4515== Location 0x600f68 is 0 bytes inside global var "static_global_a"
==4515== declared at abc.c:3
#include <stdio.h>
static int static_global_a = 0; //// <<<< this is abc.c:3
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13153
struct pthread_mutex_t is different on MIPS32 and x86_64, and thus passing a
bogus mutex pthread_cond_wait (line 72) will corrupt memory in a different way
on two platforms. This causes the subsequent call to pthread_cond_wait to fail
on MIPS and i386 but not on x86_64.
This change fixes helgrind/tests/tc23_bogus_condwait on MIPS and i386.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13001
Writing to a double is done via two store-word instructions on MIPS platforms.
Thus, Helgrind will report "Possible data race during write of size 4" twice on
subsequent locations on MIPS instead of a single "Possible data race during
write of size 8". New exp file is added to cover this case.
This fixes helgrind/tests/tc19_shadowmem on MIPS.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13000
Different error numbers on MIPS require us to add an extra exp file for this
test. EDEADLK is 45 on MIPS (and not 35), and EOPNOTSUPP is 122 (and not 95).
Furthermore, sem_post will pass due to different implementation on MIPS (in
comparison to x86_64), and thus one error less has to be reported in the log.
This fixes helgrind/tests/tc20_verifywrap.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12998
The existing tc18_semabuse.stderr.exp expects that sem_post on a bogus semaphore
will fail, yet it does not on platforms such as MIPS or ARM. This is specific to
implementation of sem_post for i386/x86_64 that has some assumptions such as that
'private' field is not clobbered. This will eventually result in different
parameter passed to syscall and thus different output is encountered.
This change fixes helgrind/tests/tc18_semabuse for MIPS.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12976
* when cond var is destroyed, in the PRE, report an error if nwaiters > 0.
* when cond_wait succeeds, get the cond var but do not create one in helgrind
(it must exist if cond_wait was done).
Report an error if cond not found (assuming this is caused by a destroy
done while the thread was cond_wait-ing).
* added a test
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12721
Even without fair scheduling, this ensures the progress
of each thread.
This avoids the test looping forever in an outer/inner
setup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12452
of this is to not have to link against -lrt because that causes
a different back-trace on certain x86 and s390x environments.
See the thread with subject
"helgrind/tests/cond_timedwait_invalid failing on x86"
on valgrind-developers for more details.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12246
quadratic growth on some apparently simple test cases. Fixes#267925.
(Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12201
the tarball generated by "make dist".
With this change running regtest from the tarball produces the same
results as a regtest on a checked out repository (on x86 that is).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12172
bucket. Instead of removing what we don't want to see in a backtrace
(e.g. path segments through libc and libpthread), we simply keep what
we do want to see. That way .exp files can be generic.
We need to make sure that GCC inlining does not get in the way. So all
the ..._WRK function in hg_intercepts.c are attributed as noinline.
The backtrace filtering is done in the new filter_helgrind script.
filter_stderr is simplified quite a bit.
Fixes bug #281468. See also the comments #5 and #6 there.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12045
The testcase used to cause a SIGILL because the address of the bogus
mutex 1 + (char*)&mx[0] denotes a memory location that will eventually
appear in a compare-and-swap instruction. That insn does not allow
memory operands that are not word-aligned. Hence, the SIGILL.
With this fix both incarnations of this testcase (in helgrind and drd)
pass.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12038
machines we need to sleep longer. See bugzilla #268623 comment #2.
So let's sleep 500ms instead of 100ms, get rid of the load
barrier and enable the testcase for s390x again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12031
