Home Original page

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

Nelson Chu nelson@rivosinc.com
Fri Oct 24 08:09:12 GMT 2025 
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.  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.


> 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?

Thanks
Nelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251024/94a65db0/attachment-0001.htm>
More information about the Binutils mailing list