mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-04 02:18:37 +00:00
35156f7ede
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
Release notes for Valgrind
~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are building a binary package of Valgrind for distribution,
please read README_PACKAGERS. It contains some important information.
If you are developing Valgrind, please read README_DEVELOPERS. It contains
some useful information.
For instructions on how to build/install, see the end of this file.
If you have problems, consult the FAQ to see if there are workarounds.
Executive Summary
~~~~~~~~~~~~~~~~~
Valgrind is a framework for building dynamic analysis tools. There are
Valgrind tools that can automatically detect many memory management
and threading bugs, and profile your programs in detail. You can also
use Valgrind to build new tools.
The Valgrind distribution currently includes six production-quality
tools: a memory error detector, two thread error detectors, a cache
and branch-prediction profiler, a call-graph generating cache abd
branch-prediction profiler, and a heap profiler. It also includes
three experimental tools: a heap/stack/global array overrun detector,
a different kind of heap profiler, and a SimPoint basic block vector
generator.
Valgrind is closely tied to details of the CPU, operating system and to
a lesser extent, compiler and basic C libraries. This makes it difficult
to make it portable. Nonetheless, it is available for the following
platforms:
- X86/Linux
- AMD64/Linux
- PPC32/Linux
- PPC64/Linux
- ARM/Linux
- x86/MacOSX
- AMD64/MacOSX
- S390X/Linux
- MIPS32/Linux
Note that AMD64 is just another name for x86_64, and Valgrind runs fine
on Intel processors. Also note that the core of MacOSX is called
"Darwin" and this name is used sometimes.
Valgrind is licensed under the GNU General Public License, version 2.
Read the file COPYING in the source distribution for details.
However: if you contribute code, you need to make it available as GPL
version 2 or later, and not 2-only.
Documentation
~~~~~~~~~~~~~
A comprehensive user guide is supplied. Point your browser at
$PREFIX/share/doc/valgrind/manual.html, where $PREFIX is whatever you
specified with --prefix= when building.
Building and installing it
~~~~~~~~~~~~~~~~~~~~~~~~~~
To install from the Subversion repository :
0. Check out the code from SVN, following the instructions at
http://www.valgrind.org/downloads/repository.html.
1. cd into the source directory.
2. Run ./autogen.sh to setup the environment (you need the standard
autoconf tools to do so).
3. Continue with the following instructions...
To install from a tar.bz2 distribution:
4. Run ./configure, with some options if you wish. The only interesting
one is the usual --prefix=/where/you/want/it/installed.
5. Run "make".
6. Run "make install", possibly as root if the destination permissions
require that.
7. See if it works. Try "valgrind ls -l". Either this works, or it
bombs out with some complaint. In that case, please let us know
(see www.valgrind.org).
Important! Do not move the valgrind installation into a place
different from that specified by --prefix at build time. This will
cause things to break in subtle ways, mostly when Valgrind handles
fork/exec calls.
The Valgrind Developers