On Feb 8, 2018, Jason Merrill <ja...@redhat.com> wrote: > On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva <aol...@redhat.com> wrote: >> On Feb 7, 2018, Jason Merrill <ja...@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.
> Which is often true of non-gas assemblers, isn't it? Uhh... I don't know. Anyway, without gas, we probably won't have view supports in .loc directives either, and then we'll have to emit the line number program ourselves, in which case we could (if we have accurate insn lengths) compute offsets and output special opcodes or byte-expanded uleb128 literals, even if the assembler doesn't support leb128. Sure enough, if we don't have accurate insn lengths, we'll have to resort to something else; for small increments without assembler support for uleb128, DW_LNS_fixed_advance_pc would probably be a more compact option than DW_LNS_set_address, if we're sure the increment is small enough. Even then, if we were to do something along these lines, when we know the offset is nonzero (i.e., we want to reset the view), we could output DW_LNS_fixed_advance_pc with the desired offset minus 1, followed by a special opcode that advances PC (resetting the view count) and emitting the line table entry, rather than using DW_LNS_fixed_advance_pc with the offset, followed by DW_LNS_copy to output the line number table without resetting the view. Same size, with the choice of resetting or not the view counter. As for when we don't know whether the offset could be zero, we have only one choice: not resetting the view counter. > So, if I've got this right: The most conservative approach to updating > the address is DW_LNE_set_address, but we definitely want that to > reset the view because it's used for e.g. starting a new function. Yup. > And if it resets the view, we need to be careful not to use it more > than once for the same address. I guess it's ok if we do that e.g. once as the one-past-the-end of a function, and then again as the entry of another function, but other than that, yeah, it shouldn't happen. [...] > And since we don't know whether the increment will be zero, we > don't want it to reset the view. Yup > OK, that makes sense. Though I expect this will come up again when > the DWARF committee looks at the proposal. Most likely. The reasoning that led me down this path was quite intricate indeed. Please let it be known that I'd be glad to join the committee's conversation when they're to discuss this proposal, if that would be of any help. Thanks, -- 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
