[Bug translator/6977] New: Incorrect resolution of variables in function scope

[Bug translator/6977] New: Incorrect resolution of variables in function scope

[prerna at linux dot vnet dot ibm dot com]

The following script fails when run on a NUMA machine :
probe kernel.function("get_page_from_freelist")
{
        printf("zone_reclaim_mode = %x\n", $zone_reclaim_mode);
}

Error :
semantic error: failed to retrieve location attribute for local
'zone_reclaim_mode' (dieoffset: 0xzone_reclaim_mode): identifier
'$zone_reclaim_mode' at scripts/zrm.stp:5:44
source:         printf("zone_reclaim_mode = %x\n", $zone_reclaim_mode)
                                                           ^

-- 
           Summary: Incorrect resolution of variables in function scope
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: prerna at linux dot vnet dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6977

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6977] Incorrect resolution of variables in function scope

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2008-10-24 05:52 -------
This arises because the variable "zone_reclaim_mode" is a global variable
defined in a different compilation unit than that of the function
"get_page_from_freelist()"
The Dwarf entry for "zone_reclaim_mode" in the CU of the function is simply a
declaration which doesnt have location info for it (since the variable is
defined as an extern int in this CU). This causes a semantic error when the stap
translator tries to fetch DWARF location info from its declaration.

To me, it appears similar to the problem of trying to access a global variable
in a different compile unit than the one in which it is defined.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6977

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6977] Incorrect resolution of variables in function scope

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2008-10-24 06:32 -------
A similar illustration would be the following script :

probe kernel.function("vmap")
{
	printf("\n num_physpages = %d",$num_physpages);
}

which fails with the following error :

semantic error: failed to retrieve location attribute for local 'num_physpages'
(dieoffset: 0xe_mmapnum_physpages): identifier '$num_physpages' at
scripts/num_physpages.stp:4:33
        source: 	printf("\n num_physpages = %d",$num_physpages);
                	                               ^

Here too, the variable "num_physpages" is defined in a different CU than the CU
of the function vmap, hence the location is not fetched. 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6977

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6977] Incorrect resolution of variables in function scope

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2008-10-24 08:09 -------
IMHO,presently, in order to find a DWARF debugging information entry for a
global object name, the translator tries to search inside the parent scope
within the relevant compilation unit inside the .debug_info section of DWARF
information.

DWARF has another section ".debug_pubnames" which is a table listing the names
of global objects whose definitions or declarations are represented by debugging
information entries owned by each compilation unit.
However, this section cant be used directly for name lookup because :
1) the offset/object-name pairs are listed on a compilation-unit basis. So one
still has to determine which CU the global variable is defined to be able to
look up.
2) The section lists tuples which list the object name for a given offset for
each CU. (so a search on names is not possible)

For fast lookup, a table is needed which hashes a given global object name to
the CU in which it is defined and the offset within the .debug_info section
where its debuging information entry would be found. 

I'm not sure if such a structure ought to be included as a separate section in
dwarf itself or whether systemtap translator must build it independently based
on kernel debuginfo..


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6977

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6977] Incorrect resolution of variables in function scope

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=6977

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |FIXED

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
This has been working for some time, via more scope-aware resolution paths for
$variables.

-- 
You are receiving this mail because:
You are the assignee for the bug.