[llvm-dev] [LLD] Linker Relaxation

[PkmX via llvm-dev]

On Jul 13, 2017 02:07, "Rafael Avila de Espindola" <
rafael.espindola at gmail.com> wrote:

PkmX via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Note that RISC-V also handles alignment as part of relaxation, so it
> isn't really optional. For example:
>
> _start:
>     mv      a0, a0
>     .p2align 2
>     li      a0, 0
>
> The assembler inserts a 3-byte padding (note: this behavior isn't
> merged yet, see: https://github.com/riscv/riscv-binutils-gdb/pull/88):

Why 3 bytes? The assembler knows the section alignment.

I can see why another relaxation would require alignments to be
revisited, but it should be possible to link without any relaxations,
no?

Cheers,
Rafael


I agree the 3-byte padding is kinda strange. RISC-V insns are always
multiples of 2 bytes and must be 2-byte aligned, so a 2-byte padding should
suffice for the linker to re-align after relaxation. Indeed, the assembler
should be able to configured to not emit any relaxation info and directly
emit the correct number of nop's (w/o R_RISCV_ALIGN), and the object file
can be linked without relaxation, but I don't think GAS can do that right
now. (There is `.option norelax`, but currently it just emits zeros in the
padding.)

So the issue remains that GAS assumes linkers will always handle alignment
(this is true for GNU ld even if --no-relax is given), so even for a basic
RISC-V port lld needs to be extended to support relaxation.

On Thu, Jul 13, 2017 at 6:07 AM, Bruce Hoult <bruce at hoult.org> wrote:
> As a concrete suggestion, here is code for deciding how many bytes of
> padding to emit.
>
> For the case of .align 2 (4 byte alignment), it will emit a minimum of 3
and
> a maximum of 6 bytes of padding. For .align 4 it emit a minimum of 15 and
a
> maximum of 30 bytes of padding.

Why does .align 2 need 3 to 6 bytes of padding though? I think for
`.p2align n` only 2^n - 2 (or 2^n - 4 without RVC) padding bytes would be
needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170713/49f6c341/attachment.html>