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