On Feb 6, 2018, Jason Merrill <ja...@redhat.com> wrote: > On 12/11/2017 09:52 PM, Alexandre Oliva wrote: >> +/* output symbol LAB1 as an unsigned LEB128 quantity. */ >> + >> +void >> +dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED, >> + const char *comment, ...)
> I'm having trouble understanding the use of symbols for views. The > configure test for gas support doesn't obviously define a symbol > anywhere; is it implicitly defined by its use in the location > directive? This could use more documentation in dwarf2out. Yeah. It's the .loc statement that assigns a view number to the view number symbol. That's documented in the gas manual, but I guess it won't hurt to add something to dwarf2out too. Will do. >> + view computation, and it is refers to a view identifier for which > "it refers" Thanks > 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. -- 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
