location lists revisited

[todd dot allen at ccur dot com (Todd Allen)]

   Thinking about how I would implement the DWARF replication approach for
   local copies of global variables has brought me back to my original
   question about this issue.  I don't think the DWARF replication approach,
   alone, will support it.  I'll reiterate the problem with a concrete
   example in 3 sources:

      source1.c:
         int global;

         function foo()
         {
            ...
            for (; global < ...; global++) {
               ... global is used ...
            }
            ...
         }

      source2.c:
         extern int global;

         function bar()
         {
            ...
            for (; global < ...; global++) {
               ... global is used ...
            }
            ...
         }

      source3.c:
         /* Notice no extern int global, nor any include files */

         function unrelated()
         {
            ...
         }

   Because global is used in a loop in both foo() and bar(), local read/write
   copies are made in both of those functions.

   That means that in both source1.o and source2.o, a location list will be
   generated for global.  In source1.o, it will describe the in-memory
   location for most of the .text in that object file, but will describe the
   in-register location for the relevant part of foo().  In source2.o, the
   location list would either do much the same thing, or because global has a
   non-defining declaration there, it might only describe in the in-register
   location for the relevant part of bar().

   Either way, how would a debugger stopped in unrelated() determine the
   location of global?  Certainly, that's something that DWARF should
   support.  (Yes, whether a debugger supports it is a QoI issue, but DWARF
   shouldn't stand in the way.)

   But regardless of which of the two location lists found by the debugger
   (or even if it tracks down both), the pc at which it's stopped won't be
   covered.  The location lists for an object can only cover PC's within that
   object file.

   If the replication approach is the consensus approach, then it seems like
   a "default" location description would be necessary to cover the "in every
   other object" case.  Probably the best way to do it would be to define
   another kind of location list element that meant "default".  Note that the
   semantics of this "default" are quite different from Ron Brender's
   proposal from last year.  I'm talking about a "default" location that
   covers not only PC's in a particular routine, but also everywhere
   *outside* the current object routine or object file.

   Going back to the DW_TAG_local_copy approach, though, this isn't necessary
   because the global would just describe its location with a location
   description, which covers the whole program.  And then that location would
   be augmented with the DW_TAG_local_copy's location.  

   Either way, the "default" location or the DW_AT_location of the global
   would need to be superseded completely by any other location list element
   or DW_TAG_local_copy's DW_AT_location for any PC ranges that they covered.
   That way, periods of time when the global copy was stale could be
   described.  And in places where both the global and local copies were
   live, a location list including both copies could be used.

   Michael Eager:  Did you say at one point that this problem was solved 
                   already?  If so, how?

-- 
Todd Allen
Concurrent Computer Corporation