Re: Modifies vs. Replaces

[Michael Eager <eager at eagercon dot com>]

Ron 603-884-2088 wrote:
> 
> >As I see it, the code which Ron presents is extremely common and
> >not at all unusual.  Using his method would mean that location
> >information would need to be duplicated for virtually every use
> >of a global variable.  Instead of one relocation entry for the
> >definition of a global variable, there would be one or more for
> >each use of a global variable.
> 
> Not so -- this characterization of the cost is far too high. The cost
> is not "each use" of the global variable, but "each non-defining declaration"
> in the common case.
>
> In the more common case, where it is valid for the value in the primary
> location to be copied back to the global location arbitrarily by
> the debugger, the cost will be exactly one extra entry in the
> location list of each non-defining declaration (together with its
> associated relocation), which is to say, one entry and relocation
> per compilation unit. That is unlikely to be significant in the
> presence of the remaining location entries that make it necessary to have
> a location list for the non-defining declaration in the first place.

It depends on whether the non-defining declaration is placed in 
the scope of the function where it applies (or is declared) or 
whether there is a single one per compilation.

Other location list entries (e.g., for registers) do not have 
relocations, so your comment about them seems irrelevant.

The cost ranges from one per compilation unit per global used, 
to one per declaration per global used.  These are redundant,
duplicated data.
 
> In the unusual case (possibly non-existant today?), the cost will
> be higher, maybe even significantly so. But that cost describes
> a case that cannot be described at all by the "appends" model.
> 
> There is a bit processing advantage in the "replaces" model as well.
> Given that a non-defining declaration has been found that has its
> own location attribute, there is no need to find and search two
> location lists to form the set of locations that apply at the PC
> of interest. I won't claim that is a big deal, however.

This does presume one particular design for a debugger.

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