Re: Introduce support for location views

[Alexandre Oliva <aoliva at redhat dot com>]

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