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
The flag DISABLE_PTHREAD_SPINLOCK_INTERCEPT is set only for MIPS32, and it is
used in DRD and Helgrind as a workaround for the issue #311690.
In short, pthread_spin_lock implementation has local branches to the start of
the function which interferes with the redirection system in Valgrind that
assumes it has to redirect each call/branch to a particular address.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13190
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
Also fix all usages of the wordFM data structure. Once upon a time
wordFM used Words but now it uses UWords.
Likewise for WordBag.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13070
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
* For tools replacing the malloc library (e.g. Memcheck, Helgrind, ...),
the option --redzone-size=<number> allows to control the padding
blocks (redzones) added before and after each client allocated block.
Smaller redzones decrease the memory needed by Valgrind. Bigger
redzones increase the chance to detect blocks overrun or underrun.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12807
#define N_FRAMES 8
(defined in libhb_core.c:3888)
implies that 'other thread' stack traces are limited to 8,
even with a bigger --num-callers.
=> document this in the manual to avoid that a user believes this is a
bug in the stack trace logic of Valgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12767
* 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
* new files include/pub_tool_groupalloc.h and coregrind/m_groupalloc.c
implementing a group allocator (based on helgrind group alloc).
* include/Makefile.am coregrind/Makefile.am : added pub_tool_groupalloc.h
and m_groupalloc.c
* helgrind/libhb_core.c : use pub_tool_groupalloc.h/m_groupalloc.c
instead of the local implementation.
* include/pub_tool_oset.h coregrind/m_oset.c : new function
allowing to create an oset that will use a pool allocator.
new function allowing to clone an oset (so as to share the pool alloc)
* memcheck/tests/unit_oset.c drd/tests/unit_bitmap.c : modified
so that it compiles with the new m_oset.c
* memcheck/mc_main.c : use group alloc for MC_Chunk
memcheck/mc_include.h : declare the MC_Chunk group alloc
* memcheck/mc_main.c : use group alloc for the nodes of the secVBitTable OSet
* include/pub_tool_hashtable.h coregrind/m_hashtable.c : pass the free node
function in the VG_(HT_destruct).
(needed as the hashtable user can allocate a node with its own alloc,
the hash table destroy must be able to free the nodes with the user
own free).
* coregrind/m_gdbserver/m_gdbserver.c : pass free function to VG_(HT_destruct)
* memcheck/mc_replace_strmem.c memcheck/mc_machine.c
memcheck/mc_malloc_wrappers.c memcheck/mc_leakcheck.c
memcheck/mc_errors.c memcheck/mc_translate.c : new include needed
due to group alloc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12341
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
memcheck.h) by changing a bunch of VALGRIND_DO_CLIENT_REQUEST_EXPR
into VALGRIND_DO_CLIENT_REQUEST_STMT for cases where the return value
of the former would be unused. (Bart Van Assche, bart.vanassche@gmail.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12226
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
