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

[Jan Beulich]

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. 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).

Jan