Re: Introduce support for location views

[Andrew Waterman <andrew at sifive dot com>]

Thanks Alex, we'll look into it.

On Thu, Jul 20, 2017 at 1:02 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jul 19, 2017, Andrew Waterman <andrew@sifive.com> wrote:
>
>> In general, the RISC-V target does not support subtraction of code
>> labels at assembly time, as the delta may be adjusted by the linker.
>
> *nod*
>
> LVU doesn't quite need subtraction of code labels, though.  The
> label-lookalikes that are used as .uleb128 operands in view expressions
> are just constants, but they aren't necessarily computed yet at their
> point of use.  They didn't have to be rejected by the RISC-V assembler,
> but they are.
>
> Now, admittedly, the assembler-generated expressions used to compute
> view numbers do compare code labels, to test whether there's an address
> change between them.  This is even simpler than other address compares
> that take place in the generation of line number programs, and it didn't
> look like the assembler refrained from resolving to constants the code
> label differences that appear in address offsets in them, e.g. in cases
> it was expected to use special opcodes, so I now, besides the
> supportability of location views on RISC-V, I have two concerns: whether
> we can/should even use such special opcodes in debug info line number
> programs on RISC-V, considering that offsets might change due to linker
> relaxations, and how usable the line number programs generated right now
> are, if linker relaxations can change offsets in ways that might not be
> reflected in the debug information.
>
>> However, the change you've proposed will at this
>> time break the RISC-V GCC port.
>
> I think there's a misunderstanding, the patchlet I included in my
> earlier message was nothing but a record of the changes I made to verify
> that the new failures Nick saw on RISC-V were no different from
> preexisting failures, because they might serve as a starting point for
> future fixes.
>
>
>> GCC checks at configure time whether
>> uleb128 supports label subtraction, and avoids it if not.  If it
>> erroneously believes label subtraction works, it will generate DWARF
>> that will not work on RISC-V.
>
> I still think checking whether the [su]leb128 operand is a constant, at
> the point of use, is too strong a requirement.  We already require it to
> resolve to a constant, and in the LVU patch I propose we check that it's
> defined (we didn't), so I'd think this ought to be enough, as long as
> you stop the assembler from resolving differences between label offsets
> to constants uniformly.  Now, maybe the [su]leb128 check I'm adding
> there is still too weak, and it should check whether the operand is
> actually resolved to a constant, besides testing whether it's defined
> and taking its value, but these would all likely be machine-independent
> desirable features; what makes RISC-V special is that it can't resolve
> label offsets to constants, and making sure it doesn't, along with the
> additional care in [su]leb128 output I propose, would suffice to get you
> guys what you need without a machine-dependent [su]leb128 pseudo-op
> handler.
>
> I hope this helps,
>
> --
> 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