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

[Alexandre Oliva <aoliva at redhat dot com>]

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

> On Thu, Feb 8, 2018 at 7:56 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
>> 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.

> 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