| 639c351a4571ffcd7f99fc90cd76fa010fa01b1a |
|
17-May-2014 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
drd/tests/atomic_var: Revert r13876.
r13876 was a workaround for false ordering introduced by platform-specific
(Solaris) code. The conclusion of an off-list discussion was that this has
to be solved in the drd tool itself and not by modifying test programs. Hence
this revert.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13980 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| 35d91d90581e78326e789051b781b11cf5483661 |
|
18-Mar-2014 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
drd/tests/atomic_var: Avoid that platform-specific code can trigger a false negative
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13876 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| 81d24c396c66dde7db2d9b567451f99081a2eab7 |
|
05-Dec-2012 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
fix 310424 --read-var-info does not properly describe static variables
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 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| cab64bca3a865a294b2c20f158c8c2182fa4eb7e |
|
12-Aug-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update .exp files for r10783.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10784 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| a1fc3a5b862cc3b5adb0eaeb4e9f4a500a074e4f |
|
21-Jul-2009 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
More regression test output tuning.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10509 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| 63c92ea799549976957f5b4d54ede744f762c56f |
|
19-Jul-2009 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
DRD no longer prints the thread ID's assigned by the Valgrind core but only those assigned by DRD itself.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10488 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| d45d99553c15a361bb797d21ec6afb9bad22d2d4 |
|
31-May-2009 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
- Added support for most of the ANNOTATE_...() macro's supported by
ThreadSanitizer.
- Modified DRD's error reporting code such that it does no longer let
the Valgrind core print the Valgrind thread ID but that it now prints
the DRD thread ID and name. Updated expected output files where
necessary.
- Modified drd/test/Makefile.am such that the tests using gcc's built-in
functions for atomic memory access such that these are only compiled when
the gcc version in use supports these built-in functions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10186 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| a1e7d7c0ce2ed543582fd6f8a336d79593cf92ad |
|
29-Jul-2008 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Removed duplicate expected output file.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8472 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| 0dbdd6348d921688f7cd749ccc3f4f00890090e3 |
|
10-Jul-2008 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Fixed line number.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8414 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|
| cca440bcba031f0f37b39ad82e840ba693dd6b9d |
|
10-Jul-2008 |
bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Added a regression test for atomic variables.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8412 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/drd/tests/atomic_var.stderr.exp
|