Created attachment 12115 [details] failing test case When I switch back and forth between '.option rvc' and '.option norvc', the alignment mechanism seems to break. When linking I get this failure: riscv64-unknown-elf-ld: lotsaregs.o(.text+0x2): 14 bytes required for alignment to 16-byte boundary, but only 12 present riscv64-unknown-elf-ld: can't relax section: bad value make: *** [lotsaregs.elf] Error 1 See attached testcase. This was run using binutils 2.33.50.20191209 (latest master git bac7c5cf) but also seen in a months-old release. Built today using crosstools-ng 1.24.0. (The error message comes from ld but I suspect the problem originates in as, so I'm filing this under as.) In another instance (no testcase, sorry) a .balign 4 failed to achieve the intended alignment, giving no error message but leaving the next instruction only 2-byte aligned.
This is a known problem. There is a proposal to the psABI to add new relocations to help fix it, but there is no timetable for a fix. One workaround is to make sure that you align before disabling rvc mode. It you do .option norvc .balign 16 add you need a 2-byte nop, then you have a problem, because we can't emit a 2-byte nop in norvc mode. So you must instead do .balign 16 .option norvc so that the 2-byte nop gets emitted before we switch to norvc mode. With the current set of relocations, there is no way for the linker to know if this is a user error or a toolchain error when we see an alignment problem, so you get a not very useful generic error. There was also a suggestion to make option norvc/rvc imply the necessary align operation itself, before changing the mode, but I'm not sure if that is a good idea or not. I think there might already be a bug report for this, but I'm too busy to look it up at the moment.
Thanks Jim. The workaround is simple and suitable. I couldn't find the duplicate bug report you suspected, and the failure mode in this case is rather unfortunate, but at least there's a record of the workaround here. I'll go ahead and close this issue.