On Thu, 20 Jan 2022 13:20:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
> due to some aggressive linker optimizations).
I don't really understand the rest of this, but we do have a subset of
LEB128 (constant expressions only). I'm not sure exactly what the
requirements are here, but one could imagine extending our assembler support
to cover them -- we might never have full support for LEB128 expressions
(because of linker relaxation), but we might be able to make more stuff
work.
I'm not sure if that helps or hurts, though, as we'll still be a special
case.
HAVE_AS_LEB128 really needs to be able to handle both constants and
difference of two labels in the same section.
Most targets resolve something like that in the assembler as constant which
they encode into sleb128 or uleb128 and put into the section that uses
those directives (typically debugging sections).
If a target performs aggressive linker relaxation, then probably some
relocation would need to be added (but one that can encode the two symbols
for the difference, so perhaps two relocations that must be consecutive or
something similar) and resolve that by the linker. Though, that would mean
that even in the debugging section offsets wouldn't be fixed during
assembly...
Differences are the hard case for RISC-V, as they can grow numerically.
That could then cause the LEB to grow in byte size, possibly violating
one of our linker relaxation invariants. The only way I've come up with
to support these would be to pad the LEBs, and I'm not sure if that's
legal.
Not sure if I'm missing something, though.
