Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb  7, 2018, Jason Merrill <jason@redhat.com> wrote:

> OK, that makes sense.  But I'm still uncomfortable with choosing an
> existing opcode for that purpose, which previously would have been
> chosen just for reasons of encoding complexity and size.

Well, there's a good reason we didn't used to output this opcode: it's
nearly always the case that you're better off using a special opcode or
DW_LNS_advance_pc, that encodes the offset as uleb128 instead of a fixed
size.  The only exceptions I can think of are offsets that have the most
significant bits set in the representable range for
DW_LNS_fixed_advance_pc (the uleb128 representation for
DW_LNS_advance_pc would end up taking an extra byte if insns don't get
more than byte alignment), and VLIW machines, in which the
DW_LNS_advance_pc operand needs to be multiplied by the ops-per-insns
(but also divided by the min-insn-length).  So, unless you're creating a
gap of 16KiB to 64KiB in the middle of a function on an ISA such as
x86*, that has insns as small as 1 byte, you'll only use
DW_LNS_fixed_advance_pc when the assembler can't encode uleb128 offsets,
as stated in the DWARF specs.  Well, now there's one more case for using
it, and it's a rare one as well.  I didn't think it made sense to add
yet another opcode with a fixed-size operand for that.

But then again, even it was an opcode used more often, it wouldn't be a
significant problem to assign it the special behavior of not resetting
the view counter.  Views don't have to be reset for the whole thing to
work, we just need some means for the compiler (who doesn't know all
offsets) and debug info consumers (who do) to keep view numbers in sync.
A single opcode for the compiler to signal to the consumer that it
wasn't sure a smallish offset would be nonzero is enough, and
DW_LNS_fixed_advance_pc provides us with just what we need, without any
complications of having to compute a special opcode, or compute a
compiler-unknown offset times min-insn-length and have that encoded in
uleb128.


> Thanks, it would be good to have this overview in a comment somewhere.

You meant just these two paragraphs (like below), or the whole thing?


diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 3cf79270b72c..56d3e14b81bf 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3183,7 +3183,33 @@ static GTY(()) bitmap zero_view_p;
 			: (N) == 0)
 
 /* Return true iff we're to emit .loc directives for the assembler to
-   generate line number sections.  */
+   generate line number sections.
+
+   When we're not emitting views, all we need from the assembler is
+   support for .loc directives.
+
+   If we are emitting views, we can only use the assembler's .loc
+   support if it also supports views.
+
+   When the compiler is emitting the line number programs and
+   computing view numbers itself, it resets view numbers at known PC
+   changes and counts from that, and then it emits view numbers as
+   literal constants in locviewlists.  There are cases in which the
+   compiler is not sure about PC changes, e.g. when extra alignment is
+   requested for a label.  In these cases, the compiler may not reset
+   the view counter, and the potential PC advance in the line number
+   program will use an opcode that does not reset the view counter
+   even if the PC actually changes, so that compiler and debug info
+   consumer can keep view numbers in sync.
+
+   When the compiler defers view computation to the assembler, it
+   emits symbolic view numbers in locviewlists, with the exception of
+   views known to be zero (forced resets, or reset after
+   compiler-visible PC changes): instead of emitting symbols for
+   these, we emit literal zero and assert the assembler agrees with
+   the compiler's assessment.  We could use symbolic views everywhere,
+   instead of special-casing zero views, but then we'd be unable to
+   optimize out locviewlists that contain only zeros.  */
 
 static bool
 output_asm_line_debug_info (void)


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer