Re: location lists

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

> 
> I'm confused about why you think multiple entries are needed for
> a single simple non-moving global.
> 
> The global variables are all described in .debug_pubnames
> and any given global is described there exactly once.
> And for .debug_aranges, each global is also described once
> (unless it's one of the ones that don't stay in one place).
> (Once across all compilation units, not once-per-compilation-unit)
> 

   But the global I'm talking about isn't non-moving.  It's just "rarely
   moving".  It "moves" when there's a local register temp of it that has a
   more recent value that hasn't been propagated to the in-memory copy yet.
   (Actually, it "moves" when there's a local register temp, period, just
   coexisting with the in-memory copy instead of overriding it for a time,
   like it does when it has a more-recent value than the in-memory copy.)

   So, I need a loclist to describe that, right?  And loclists are PC ranges
   associated with locdescs.  But the PC ranges are "relative to the base
   address of the compilation unit referencing this location list".  That
   means I realistically can only describe PC ranges inside the current
   compilation unit.  (Anything more would be guesswork about where the
   compilation unit will end up in an executable.)  That means that it will
   seem that outside the current compilation unit, the global variable has no
   location.

   Or at least this is what I get from my reading.  Did my reasoning go awry
   somewhere?

   Assuming not, then the only solution is for every compilation unit to
   describe the global variable, because only they can produce a loclist that
   correctly describes where the global is within the PC range of their
   compilation units.  And then the debugger is responsible for figuring out
   that all those separate descriptions are really the same variable and
   coalescing them (and their loclists) into a single definition.  

   But even aside from the debugger's problems, the solution is
   impossible/prohibitively hard, because not all compilation units can know
   about all global variables.

   So, is there some solution to this that eludes me?

-- 
Todd Allen
Concurrent Computer Corporation