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

[Fangrui Song <i@maskray.me>]

On Wed, Sep 25, 2024 at 10:44 PM Nelson Chu <nelson@rivosinc.com> wrote:
>
> Hi Jan,
>
> I think this should be the correct way to do it for mixed data/text cases, although the current compiler, both gcc and llvm, won't generate this kind of code, it should be worth trying and do something in advance.  Since there still isn't any spec that gives a rule for mixed data/text cases (https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/210#issuecomment-929769772), I think it should be fine to go ahead and try :-)
>
> I am not sure who should need to know the changes, so I at least cc Kito and Maskray.  Please feel free to cc or reference this information to anyone who will need to know.
>
> Thanks
> Nelson
>
> On Tue, Sep 24, 2024 at 4:31 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 04.09.2024 01:02, Palmer Dabbelt 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.
>>
>> Mind me asking if there has been any progress here?
>>
>> Jan

For the new test relax-align.s, gas without this patch seems to
produce `ret` at a wrong location.
In contrast, `llvm-mc -filetype=obj -triple=riscv64 -mattr=+relax`
produces the correct `ret`.

I haven't checked the functionality, but the new test looks correct.

The behavior difference from the current behavior (wrong; not used by
GCC codegen) should not hold off landing this patch.


(Dropping maskray@google.com as I am leaving Google and the email
address will bounce soon :)