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

[Jan Beulich]

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

Jan