666ee9df4c2b6d801b199b8168208dbb46573c9d |
|
09-Aug-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
This patch implements reading the directory information for source files in the dwarf3 reader. Basically, the change consists in replacing in the DiInlLoc struct const HChar* filename; /* caller source filename */ by UInt fndn_ix; /* index in di->fndnpool of caller source dirname/filename */ A similar change is done in DiVariable struct, as the read_filename_Table code is shared between the inline info reader and the varinfo reader. Note however that outputting dirname in variable description is not done. Unclear if that is desired or not. It should be trivially doable however. Replacing filename by fndn_ix implies a bunch of semi-mechanical changes. The code to read the directory names is in the new function static XArray* read_dirname_xa (struct _DebugInfo* di, const HChar *compdir, Cursor *c, Bool td3 ) Note that readdwarf.c and readdwarf3.c have significant duplicated logic. Would be nice to integrate these 2 dwarf readers in one single reader. This function is directly inspired from an equivalent piece of code in readdwarf.c. Modified memcheck/tests/varinfo5.vgtest to test the dirname appears in the inlined functions. Impact on memory is neglectable (a few Kb on a big executable). git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14245 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/memcheck/tests/varinfo5.stderr.exp
|
e2d41dc65a214f6950f42d0b02cd9cc2d932d927 |
|
08-Jul-2014 |
philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Apply text_debug_bias to inline IP extracted from dwarf3 Without this biasing, inline info is not correct for shared objects. Updated test varinfo5 to use --read-inline-info=yes and added an inline test case. Note: the varinfo reader does not understand the inlining info, and so variables in inlined functions are not properly described. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14146 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/memcheck/tests/varinfo5.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/memcheck/tests/varinfo5.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/memcheck/tests/varinfo5.stderr.exp
|
1c4a48744762f0ab4578919daa6fac0cf718c4ad |
|
30-Apr-2009 |
njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Use -q on varinfo tests to avoid platform-specific differences in number of allocations. This allowed two .stderr.exp files to be merged for varinfo6. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9681 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/memcheck/tests/varinfo5.stderr.exp
|
fb27ca7c4f793dea4e95e01c5e1a9b7b0a4288ba |
|
02-May-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Update expected outputs following merge of branches/OTRACK_BY_INSTRUMENTATION. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7985 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/memcheck/tests/varinfo5.stderr.exp
|
b8b79addf04dd5d0b558916e26df0b1927cbd758 |
|
03-Mar-2008 |
sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> |
Merge in the DATASYMS branch. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7540 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/memcheck/tests/varinfo5.stderr.exp
|