Re: Modifies vs. Replaces

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

> 
> I have a question about what a compiler would put in the range list
> for a non-defining entry.  Using Todd's examples, he would put in
> the start and end locations of the compilation unit containing
> the non-defining declaration.  Why he selected those numbers, 
> I can't guess, but I know that globals have valid lifetimes 
> outside that range.  How should this range list be specified?
> 

I'll explain my rationale for the abbreviated range in the non-defining
declaration.

Remember that the beginning and ending addresses in a location list are
relative to the base address of the compilation unit referencing the location
list.  This is a very nice feature when describing variables whose lifetimes
are completely contained within that compilation unit, because it reduces the
number of relocations needed.  But it makes it tricky to describe a range of
addresses that starts at the absolute address 0 and ends at the absolute
address 0xffffffff (for 32-bit).

In DWARF2.0, to describe a beginning address with an absolute value of 0, it
would need to contain the negative offset of the compilation unit's base
address: 0 - base_address.  Similarly, the ending offset would need to
contain the difference between the last address and the compilation unit's
base address: 0xffffffff - base_address.  Because, in most compilation
systems, that information isn't known until link-time, this calculation has
to be stored as a relocation.  Using the symbols from various
process-specific ELF/gABI documents, this requires a relocation with a
calculation of A - S.  I couldn't find support for such a relocation in any
of the processor-specific ELF/gABI standards that I could lay hands on (PPC,
i386, MIPS), so I'm operating on the assumption that support for it is rare.

Approaches for dealing with it:

   1) Use abbreviated address ranges that can be determined at compile-time, 
      without needing any relocations.  

      This is the approach I used in my example.

      The fact that the address ranges are abbreviated didn't seem to be much
      a burden, because the non-defining declarations would only be
      encountered within a scope which was covered by the compilation unit
      containing the location list.  For a debugger that collected all the
      non-defining declarations from all over the program, I suppose the
      merging of information would be more of a hassle, but still doable.

   2) Require assemblers & linkers for DWARF2.1 producers support this to add
      a relocation type which supports the A - S calculation, so that they
      could describe address ranges that covered the whole range from
      absolute 0 to absolute 0xffffffff.  [Probably this is made unnecessary
      by approach #3:]

   3) Use the new DWARF2.1 support for "Multisection Location and Range
      Lists".  They can be used to reset the base address to 0, and then
      ordinary relocations can be used:

         [0xffffffff 0x0            (set base address to 0)
          0x0     .. symbol1
          symbol2 .. 0xffffffff]

      The references to symbol1 and symbol2 can be described with ordinary
      R_PPC_ADDR32, R_386_32, or R_MIPS_32 relocations, for instance.

I only thought of approach #3 today.  It has appeal.  Approach #1 still
requires fewer relocations, though, and it doesn't seem terribly problematic
from an implementation point-of-view.  Still, if the consensus is that the
whole range of addresses should be described, that'll be OK with me.

-- 
Todd Allen
Concurrent Computer Corporation