.option norvc disables all 16-bit instructions in binutils

[yclwlcy]

According to the RISC-V Assembly Programmer's Manual, .option norvc is equivalent to .option arch, -c. However, .option norvc disables all 16-bit instructions in binutils. Should the binutils implementation be modified to align with the spec?

Thanks!

[pz9115]

I think Nelson had a solution in Binutils part, please check the follow issue and PR, thanks.

#445
riscv-non-isa/riscv-elf-psabi-doc#393

[TommyMurphyTM1234]

Shouldn't there be an issue logged upstream against Binutils (ld?) for this? And maybe against the LLVM linker too? And other linkers such as Mold and Gold? Or does it need to be addressed in the ABI spec first?

[cmuellner]

The ASM manual states:

NOTE: There is a difference between .option rvc/.option norvc and .option arch, +c/.option arch, -c. The latter won't set EF_RISCV_RVC in the ELF flags.

So, the ASM manual does not state that .option arch, -c and .option norvc are equivalent. And the documented difference is the reported difference.

[TommyMurphyTM1234]

Isn't this issue a duplicate of this one:

• relaxation alignment issues when both rvc and norvc code present #445

Do we actually need both issues open or can they be "merged"?

[yclwlcy]

Thanks for the responses.
I’d like to clarify my question. My primary concern is about the assembler (not the linker). Consider the following assembly code examples.

Example 1:

.attribute arch, "rv64ic_zcb"
.option arch, -c
c.lbu x8, (x15) # Zcb instruction

Example 2:

.attribute arch, "rv64ic_zcb"
.option norvc
c.lbu x8, (x15) # Zcb instruction

Example 1 can be assembled, but Example 2 cannot be assembled.

[TommyMurphyTM1234]

Hi @yclwlcy - so the issue is that .option norvc might have been intended to disable C extension 16-bit compressed instructions but, in practice, actually disables ALL 16-bit instructions including those that are part of other non-C RISC-V extensions (e.g. Zcb)?

I presume that .option norvc is already so widely employed that just saying "don't use it" isn't a practical solution?

[yclwlcy]

Hi @yclwlcy - so the issue is that .option norvc might have been intended to disable C extension 16-bit compressed instructions but, in practice, actually disables ALL 16-bit instructions including those that are part of other non-C RISC-V extensions (e.g. Zcb)?

Yes.

I presume that .option norvc is already so widely employed that just saying "don't use it" isn't a practical solution?

I suggest modifying the behavior of .option norvc as follows.

   else if (strcmp (name, "norvc") == 0)
     {
       riscv_update_subset (&riscv_rps_as, "-c");
       riscv_set_arch_str (&riscv_rps_as.subset_list->arch_str);
       riscv_set_rvc (false);
+      if (riscv_subset_supports (&riscv_rps_as, "zca"))
+        riscv_set_rvc (true);
     }

[TommyMurphyTM1234]

Hi @yclwlcy - so the issue is that .option norvc might have been intended to disable C extension 16-bit compressed instructions but, in practice, actually disables ALL 16-bit instructions including those that are part of other non-C RISC-V extensions (e.g. Zcb)?

Yes.

I presume that .option norvc is already so widely employed that just saying "don't use it" isn't a practical solution?

I suggest modifying the behavior of .option norvc as follows.

   else if (strcmp (name, "norvc") == 0)
     {
       riscv_update_subset (&riscv_rps_as, "-c");
       riscv_set_arch_str (&riscv_rps_as.subset_list->arch_str);
       riscv_set_rvc (false);
+      if (riscv_subset_supports (&riscv_rps_as, "zca"))
+        riscv_set_rvc (true);
     }

Apologies if any of these are dumb questions/comments but...

1. I guess that the code snippet above comes from here?

• https://github.com/bminor/binutils-gdb/blob/5cca20f614694ba6af3c10ca5bb93c32cdb9522b/gas/config/tc-riscv.c#L4862-L4867

2. Is this a good solution given that it means that .option norvc silently becomes a nop if the target (?) happens to support Zca and this may come as an unpleasant surprise to the user?
3. Are there, or might there be in the future, other non C extensions that use 16-bit instruction encodings meaning that the check above would have to be updated to check for them too?

[yclwlcy]

1. I guess that the code snippet above comes from here?

• https://github.com/bminor/binutils-gdb/blob/5cca20f614694ba6af3c10ca5bb93c32cdb9522b/gas/config/tc-riscv.c#L4862-L4867

Yes.

2. Is this a good solution given that it means that .option norvc silently becomes a nop if the target (?) happens to support Zca and this may come as an unpleasant surprise to the user?

Yes, just like .option arch, -c.

3. Are there, or might there be in the future, other non C extensions that use 16-bit instruction encodings meaning that the check above would have to be updated to check for them too?

Just let them imply zca, like existing extensions including 16-bit instructions.

[TommyMurphyTM1234]

1. I guess that the code snippet above comes from here?

• https://github.com/bminor/binutils-gdb/blob/5cca20f614694ba6af3c10ca5bb93c32cdb9522b/gas/config/tc-riscv.c#L4862-L4867

Yes.

Thanks.

2. Is this a good solution given that it means that .option norvc silently becomes a nop if the target (?) happens to support Zca and this may come as an unpleasant surprise to the user?

Yes, just like .option arch, -c.

Sorry - where is it specified and/or implemented that .option arch, -c becomes a nop if the target supports Zca?

3. Are there, or might there be in the future, other non C extensions that use 16-bit instruction encodings meaning that the check above would have to be updated to check for them too?

Just let them imply zca, like existing extensions including 16-bit instructions.

Sorry - I don't understand what you mean. Maybe you can clarify?

BTW - the link in the original post is broken:

According to the RISC-V Assembly Programmer's Manual,

[yclwlcy]

2. Is this a good solution given that it means that .option norvc silently becomes a nop if the target (?) happens to support Zca and this may come as an unpleasant surprise to the user?

Yes, just like .option arch, -c.

Sorry - where is it specified and/or implemented that .option arch, -c becomes a nop if the target supports Zca?

In binutils, C and Zca can be set at the same time. If we remove C from rv32ic_zca using .option arch, -c, we will get rv32i_zca, which means .option arch, -c actually has no effect.

3. Are there, or might there be in the future, other non C extensions that use 16-bit instruction encodings meaning that the check above would have to be updated to check for them too?

Just let them imply zca, like existing extensions including 16-bit instructions.

Sorry - I don't understand what you mean. Maybe you can clarify?

In binutils, all the extensions which contain 16-bit instructions imply zca. So if we add a new extension which contains 16-bit instructions, we can simply let it imply zca instead of updating the checking mechanism.

BTW - the link in the original post is broken:

According to the RISC-V Assembly Programmer's Manual,

It seems to be moved to RISC-V Assembly Programmer's Manual. Thanks for reminding!

[TommyMurphyTM1234]

What needs to be done in order to resolve and close this issue?

[TommyMurphyTM1234]

What needs to be done in order to resolve and close this issue?

Anybody?
As far as I can see this issue needs to be addressed elsewhere - e.g. in upstream Binutils and/or the RISC-V Assembly Programmer's Manual?