Why do we need to use a non-zero view identifier for a zero view? Why
can't we always use 0 instead of the bitmap?
We assign view ids before we can determine whether the assigned view id
will be a zero view. That's because we scan insns forward, and debug
binds take effect at the next .loc directive, which might be hundreds of
insns after the first reference (lots of intervening debug binds before
the insn that will take the next view), and insns that would cause the > .loc directive to be at a different address from that of the previous
.loc might be anywhere between those two loc-generating insns, before or
after the bind. So, by the time we have to assign an id to the view, we
don't know whether we'll find an insn that sets RESETTING_VIEW_P before
we reach the loc-emitting insn that will take that view id.
It made more sense to me to assign the ids uniformly, and then mark
those that we find to be zero when we reach them, than to scan forward
(potentially O(n^2)) to tell in advance. This also reduces differences
in view id tracking between gcc-internal and asm view assignment.
DW_LNS_fixed_advance_pc is the only opcode that may change the
address without resetting the view. It is available for compilers
to use when an address change is uncertain, e.g., when advancing
past opcodes that may expand to an empty sequence,
e.g. possibly-empty alignment sequences, optional no-operation
opcodes or the like.
+ if (debug_variable_location_views && table->view)
+ push_dw_line_info_entry (table, LI_adv_address, label_num);
It looks like you'll always use DW_LNS_fixed_advance_pc when we don't
have .loc support. Does that mean that the view never gets reset?
No, table->view will be zero if we have crossed an insn that
RESET_NEXT_VIEW, and then we'll use a LI_set_address.
I'm uncomfortable with the special handling of this opcode; it isn't
special in DWARF5 except as a fallback if more compact encodings
aren't usable. Currently GCC is even more conservative than this, and
always use a relocation (DW_LNS_set_address); if we can use D_L_f_a_p
instead, I would expect that to help with link times. It seems wrong
to use it only in the context of view support.
We didn't use it before, but if we use, that's ok. We don't *have* to
reset the view number to zero at a PC change. It would be all right to
never reset it, as long as the compiler and the debug info consumer
agrees about it. Since in some cases the compiler has to assign views
itself (when the assembler doesn't support views), but it can't tell
whether there will be a PC change (e.g. at an align), we need some
mechanism that predictably refrains from resetting the view number,
otherwise the compiler might pick a view number based on a possibly
incorrect assumption about whether the align changes PC or not, and then
it might not match what the consumer, that knows whether the PC
advanced, would compute. To make it concrete:
# ...
.L352:
# .loc 1 533 view 3 (internal compiler tracking, no assembler support)
mov r12 <- whatever
# DEBUG x => r12
.balign 32
.L353:
# .loc 1 480 view <?>
Consider you're the compiler and you're generating a view-augmented
loclist for variable x. You have to indicate the view number at .L353
for the range that starts there, and possibly for the range that ends
there.
But is the view number 4 or 0? Namely, does .balign advance PC or not?
The compiler can't possibly know. So if it guesses .balign does advance
PC and assign a view number zero at .L353, but it guesses wrong, that
will be indistinguishable from view number zero at say .L350, because
the PC is the same. The debug info consumer will see no PC change and
assign view number 4 to the line number table entry correspoding to the
.loc directive with view <?>, but it won't find any loclist referencing
that view number. Conversely, if the compiler guessed .balign did not
advance PC, it would assign view number 4 to .L353, but then, with your
suggestion, the debug info consumer would instead assign it view number
zero, and we'd be out of sync.
That's why we need an opcode that enables the compiler and the debug
info consumer to remain in sync, disregarding a potential PC change that
would cause a view reset, because the compiler can't predict whether or
not there will be an actual PC change.
Would it make sense to say for *all* opcodes that the view is reset if
and only if the address actually changes?
I don't see how to keep compiler and consumer in sync with this
arrangement. That's why I introduced the one exceptional opcode.
How are we coordinating the line number table and location list
versions of the view counter?
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.
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.