[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

["roland at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #4 from roland at redhat dot com  2009-05-06 19:45 -------
Hmm.  I am concerned by the idea of relocs for DWARF sections in final-linked
objects.  That is a hassle that consumers have not had to handle before. 
(AFAIK only consumers that handle ET_REL pseudo-final objects such as Linux
kernel .ko modules cope with reloc sections at all.)

I think what's ideal in the abstract is that the location expression indicates
how the variable is really accessed, i.e. loading the address from the GOT or
whatever it really does.

That might not always be possible in the defining declaration.  e.g., when the
definition is in a CU where there are no accesses, perhaps it can't tell
whether other CUs will be using direct addressing (e.g. @GOTOFF) or
GOT-indirect.

I read DWARF 3 section 4.1 item 4 to suggest that there should be a defining
DW_TAG_variable whose DW_AT_location can be the "base" one, i.e. direct address
in the definer, plus non-defining DW_TAG_variable (with DW_AT_declaration) DIEs
whose DW_AT_location expressions indicate how the variable is accessed in each
scope using it.  So, in the "main program" CU the DW_TAG_variable should have
DW_AT_declaration, DW_AT_external, and a DW_AT_location describing the main
program's copy (or its GOT lookup if PIC).  In the non-defining accessing CUs
in a DSO, there should be a similar DIE whose DW_AT_location describes that
DSO's GOT lookup, etc.  If the defining CU also contains accesses, then the
defining DW_TAG_variable's DW_AT_location would describe the GOT access if
that's what that CU uses, and then no DIE anywhere would have the direct
address location expression for the DSO initializer/copy.

I don't know how ready GDB et al are to cope with this, but it seems like the
"correct" route to me.  They'd have to find the right DIE for the scope of the
access, so it has the appropriate location expression.  For "blind" global
lookups, it would have to be sure to use the "dominating" DIE, i.e. choose one
somewhere in the main program before the defining definition in the DSO.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040