[RFC] RISC-V: Set rvc elf_flags according to mapping symbols

[Nelson Chu]

On Fri, Oct 24, 2025 at 5:44 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 24.10.2025 10:09, Nelson Chu wrote:
> > On Fri, Oct 24, 2025 at 2:14 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> >> On 24.10.2025 03:57, Nelson Chu wrote:
> >>> According to riscv psabi mentions rvc elf_flags,
> >>> This bit is set when the binary targets the C ABI, which allows
> >> instructions
> >>> to be aligned to 16-bit boundaries (the base RV32 and RV64 ISAs only
> >> allow
> >>> 32-bit instruction alignment).
> >>>
> >>> There are several ways to enable/disable c/zca extension for current
> >> assembler.
> >>> The following list the setting orders,
> >>> 1. --with-arch configure option
> >>> 2. -march option
> >>> 3. .attribute directive
> >>> 4. .option arch/rvc/norvc
> >>>
> >>> Once the c/zca extensions are enabled in the above four cases, the
> >> current
> >>> assembler will set rvc elf_flags, even if the code hasn't been affected
> >> by
> >>> c/zca at all.  For example,
> >>>
> >>> % cat a.s
> >>> .text
> >>> .option norvc
> >>> norvc_func:
> >>> nop
> >>> % riscv64-unknown-elf-as -march=rv32ic a.s -o a.o
> >>> % riscv64-unknown-elf-objdump -d a.o
> >>> ...
> >>> Disassembly of section .text:
> >>>
> >>> 00000000 <norvc_func>:
> >>>    0: 00000013                nop
> >>> % riscv64-unknown-elf-readelf -hs a.o
> >>>
> >>> ELF Header:
> >>> ...
> >>>   Flags:                             0x1, RVC, soft-float ABI
> >>> ...
> >>> Symbol table '.symtab' contains 7 entries:
> >>>    Num:    Value  Size Type    Bind   Vis      Ndx Name
> >>>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
> >>>      1: 00000000     0 SECTION LOCAL  DEFAULT    1 .text
> >>>      2: 00000000     0 SECTION LOCAL  DEFAULT    2 .data
> >>>      3: 00000000     0 SECTION LOCAL  DEFAULT    3 .bss
> >>>      4: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 norvc_func
> >>>      5: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 $xrv32i2p1
> >>>      6: 00000000     0 SECTION LOCAL  DEFAULT    4 .riscv.attributes
> >>>
> >>> The above a object is actually a norvc object, which only allows 32-bit
> >>> instructions, but the rvc elf_flags was turned on by the -march option.
> >>
> >> Is it? The psABI text says more than what you quote: "When linking
> objects
> >> which specify EF_RISCV_RVC, the linker is permitted to use RVC
> instructions
> >> such as C.JAL in the linker relaxation process.  " Therefore "taking
> away"
> >
> > the flag from an object where so far it was set is first of all at risk
> of
> >> causing regressions.
> >
> >
> > Well if the object is actually an norvc object, then linker shouldn't do
> > rvc relaxation for it, but now it may do since the rvc flag may be turned
> > on, it's a bug actually.
>
> Why would that be a bug? The use asked for C.

>  How to make sure if the object allows rvc or not
> > can check the mapping symbols, that said if all mapping symbols don't
> allow
> > c, then it shouldn't do any rvc relaxation for this object in linker.
> > There was also a PR to resolve related stuff,
> > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/393,the
> current
> > linker may do the rvc relaxation on norvc code.
>
> I wouldn't think the mapping symbols (ought to) have this much power. Imo
> the header flag is the main source of information here.
>
> >> Imo we can't get away without another command line
> >> option, indicating "set bit on demand". The only place where it might
> make
> >> sense to imply such behavior (still with a small risk of regressing
> >> someone) is when the only request for C was the configure-time setting.
> In
> >> all other three cases you mention the explicit request imo needs to be
> >> honored (in the absence of other information, i.e. said new command line
> >> option or whatever equivalent thereof - could also be a directive, of
> >> course).
> >>
> >
> > Just to be sure, in case I misunderstood this description.  Aside from
> the
> > configure option, once -march turns on rvc, it's file level setting, so
> > other function-level .option directives that turn off c shouldn't affect
> > the rvc header settings?  Well, this makes sense, thanks for that tip.
> But
> > the .attribute arch directive is also a file-level setting, and its
> > priority is higher than the -march option, which means the setting will
> > overwrite the -march for the file.  So if the .attribute arch directive
> > doesn't allow c means the whole file shouldn't allow any rvc instruction,
> > so the rvc flags should be turned off?
>
> Or more generally: Any explicit request to turn on C should turn on the
> header flag. (I can't really say much about .attribute, as I know too
> little there.)
>

Yeah, this is what the current assembler does.  Once any explicit directive
or options turned on C, regardless of whether it actually affects the code
assembly, as long as the architecture parser parsed, it will turn on the
rvc header flags.  For example,

% cat tmp.s
.option rvc
.option norvc
.globl _start
_start:
        call _start
% riscv32-unknown-elf-as tmp.s -o tmp.o
% riscv32-unknown-elf-ld tmp.o
% riscv32-unknown-elf-objdump -d a.out

a.out:     file format elf32-littleriscv


Disassembly of section .text:

00010074 <_start>:
   10074: 2001                 .insn 2, 0x2001

The call cannot be relaxed to c.jal since the .option norvc should disable
the c extension for the call, but since the rvc header was turned on,
linker will still do the rvc relaxation.  That's what the psabi PR,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/393
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/393,the>, wants
to resolve - linker should check the mapping symbol before doing any
relaxation since the mapping symbols should record the right information
for function-level architectures.  However, the psabi issue is different
with the rvc header issue, its linker should do relaxations according to
mapping symbols (function-level) rather than just refer to elf header
(file-level).  I just think turning on the rvc header for above tmp.o is
weird because there isn't any code allowed to be c instruction because of
the .option norvc directive.

Thanks
Nelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251028/8846f7ad/attachment-0001.htm>