Location lists: Another use

[Michael Eager <eager at eagercon dot com>]

I thought of an example of using location lists (and non-defining
declarations) which may be different from the common use to 
describe a register copy of a global value.

This is based on a proposal for an enhancement to our C compiler
when I was at Microtec Research.  It was never implemented, so
there are probably places where it is sketchy and incomplete.  
Also no detailed design was done on how it might use Dwarf 2.
Please try not to pick it apart to show whatever flaws you might 
see in it.  I'm presenting it as an example of a reasonable use
for location lists, not as a completed design.

The proposal was to support "thread global storage" in our compiler.
Global declarations in certain compilation units would be 
identified as being duplicated for each thread, rather than there
being a single copy.  For each thread, there would be a set of
variables which would be global to all of the specified compilation
units.  Additionally, there would be real global variables, shared
by each thread.  Generally, thread local variables would be referenced
as offsets from a register, while globals would have absolute addresses.

One possible way to describe a thread global would be to have
a location expression which specifies a register and offset.
But there might not be a global register which always contained
the location of the current thread's data (e.g., x86 has too
few registers to dedicate one for a global pointer).  So let's 
look at a scheme where there are multiple location list entries
for these globals.

Let's say that the linker allocates fixed areas for thread globals
for each of a specified number of threads (a reasonable assumption
given the similar functionality in our linker).  Such a linker
might merge the location lists for each of the globals to create
a location list which points to each of the locations where a 
version of the global exists.  The range list for each of these
locations would cover the entire program.

(There might be other ways to implement this; this is not 
presented as the best or only way, merely as a reasonable choice
of implementation.)

In this case, the debugger, which would need to understand that
there were separate global areas for each thread, would identify
the global location which was appropriate for the current version
of a variable based on the currently active thread.  When the 
user was working with a single thread, only the one location
would be referenced.  If a user wanted to see (or modify) all
of the values for all threads, all locations would be referenced.

I believe that this is a reasonable description completely 
encompassed by the current Dwarf 2 standard.  Clearly, Dwarf 2
does not describe threads, but this doesn't appear necessary.
Todd will probably describe identifying the correct memory
location for a global as a heuristic; I'd describe it as the
debugger understanding the run time environment in which it
operates and acting appropriately.  

In summary, I think that this is an example of a use of location
lists which is (a) reasonable, (b) realistic, (c) practical,
and (d) compliant with the Dwarf 2 standard.   I would not like
to see the Dwarf 2 specification constrained so that uses like
this which are not currently anticipated by the standard are
precluded.


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077