[PATCH 2/3] RISC-V: correct alignment directive handling for text sections

[Nelson Chu]

Probably refer to this,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/210#issuecomment-929769772

On Wed, Sep 4, 2024 at 7:03 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:

> On Mon, 12 Aug 2024 08:08:04 PDT (-0700), jbeulich@suse.com wrote:
> > .insn or data emitted inside text sections can lead to positions not
> > being at insn granularity. In such situations using alignment
> > directives should reliably enforce the requested alignment.
> > Specifically requests to align back to insn granularity may not be
> > ignored (where, as a subcase thereof, the ordering of ".option norvc"
> > and e.g. ".p2align 2" should not matter; so far the alignment directive
> > needs to come first to have any effect). Similarly ahead of emitting
> > NOPs alignment first needs to be forced back to insn granularity.
> >
> > The new testcases actually point out a corner case issue in the
> > disassembler as well, which is being corrected at the same time: We
> > don't want to print "0x" without any subsequent digits.
>
> Sorry for being slow here.  Nelson and I talked about this a few times.
> IIRC a bunch of the complexity in the code was related to trying to
> avoid mixing RVC instructions into non-RVC regions in order to re-gain
> alignment.  I remember there being some reason that we didn't want to
> emit instructions when changing rvc->norvc, but I can't remember what
> that reason was.  So maybe I'm just crazy here...
>
> Jim might remember?  IIRC he was at least sitting there talking about
> this stuff as it was getting fixed, I forget if he wrote the code.
>
> That said, I think you just found another bug: certainly ignoring the
> alignment directive is going to break things, so that's bad.  I don't
> see anything wrong with the actual code here, though...
>
> So Nelson is going to run some regressions and see what's up.  If they
> all pass and nobody can remember a reason this wouldn't work, then I
> think we just go with it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240904/169fcdf5/attachment-0001.htm>