Issue 210314.1: Eliminate all indefinite antecedent

Author: David Anderson
Champion: Ron Brender
Date submitted: 2021-03-14
Date revised:
Date closed: 2022-02-07
Type: Editorial
Status: Accepted
DWARF Version: 6
Section various, page various.

Goal  of the changes:
Eliminate all indefinite antecedents in the DWARF5 standard (places
where the word 'it' is unclear in what the word refers to).

=====
General comments

While there are well over 200 lines in the document using the word  'it', I could 
only find seven that seem to have the possibility of misinterpretation.

Elimination of the ambiguity is straighforward: Replace 'it' with intended 
reference wording.

Here are seven changes editor may find it worthwhile implementing.  In a few cases 
here one might need to refer to the document to see the 'indefiniteness'
of the antecedent.

Document lines here were reformatted to fit shorter lines for presentation as an 
ISSUE.

The Editor suggested I present all these as one issue.  Here numbered IND 1 through 
IND 7.  IND stands for Indeterminate.

=====
The changes

IND 1:Page 10 lines 10-14
In a string type, the DW_AT_byte_size attribute is re-defined to always describe the
size of the string type. (Previously it described the size of the optional string 
length data field if the DW_AT_string_length attribute was also present.) In addition, 
the DW_AT_string_length attribute may now refer directly to an object that contains 
the length value.

-type. (Previously it described the size of the optional
+type. (Previously DW_AT_byte_size described the size of the optional


IND 2: Page 163, lines 33-36
Note that the function to which the prologue end applies cannot be directly determined
from the line number information alone; it must be determined in combination with the
subroutine information entries of the compilation (including inlined subroutines).

-information alone; it must be determined in combination
+information alone; the function must be determined in combination

IND 3: Page 164 lines 33-34
All of the other line number program opcodes that affect the address register add a 
delta to it. This instruction stores a relocatable value into it instead. 

-stores a relocatable value into it instead.
+stores a relocatable value into the address register instead.

IND 4: Page 170 lines 20-23
The DW_MACRO_import entry instructs the consumer to replicate the sequence of 
entries following the target macro header which begins at the given .debug_macro 
offset, up to, but excluding, the terminating entry with opcode 0, as though it 
occurs in place of the import operation.

-as though it occurs in place of the import operation.
+as though the sequence of entries occurs in place of the import operation.

IND 5: Page 172 lines 33-35
The CFA column defines the rule which computes the Canonical Frame Address value; 
it may be either a register and a signed offset that are added together, or a DWARF
expression that is evaluated.

-Canonical Frame Address value; it may be either a register
+Canonical Frame Address value; the rule may be either a register 

IND 6: Page 347 lines 2-4
If the compiler determines that the value of an object is constant (either throughout
the program, or within a specific range), it may choose to materialize that constant
only when used, rather than store it in memory or in a register.

-a specific range), it may choose to materialize that
+a specific range), the compiler may choose to materialize that

IND 7: Page 405 lines 20-22
This section has a similar format to the .debug_loclists section in a non-split object,
but it has some small differences as explained in Section 7.7.3 on page 226.

-section in a non-split object, but it has some small
+section in a non-split object, but the section has some small 

--
2022-02-07:  Accepted (change "rule" to "rule may indicate")