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.

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. 

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..

This has been working for some time, via more scope-aware resolution paths for $variables.