Zcmt relaxation of single *.S-source bare metal code

Placeholder Henrik Fegran
2024-08-02T08:01:50Z

There are cases where compilation of a single, bare-metal .S-file with the zcmt-flag march-flag enabled causes the linker to replace jumps inside the assembly with table jump instructions - this creates several issues and does not really make sense to me:
1. The program and linker has no way of knowing the initial value of the jvt-register (jvt is not necessarily read-only), thus the address of the table is unknown. To make sense, the code also needs to initialize this register with the address of the table it wants to use.
2. The table itself is not created (I believe this is the case - in a previous version of binutils, the content at address 0 would be overwritten)
3. Will break manually crafted assembly files that uses manually written table(s) and cm.jalt/cm.jt instructions.
4. Will break assembly tests that do not explicitly use zcmt (but leaves the march flag enabled), as the program jumps will get corrupted due to lack of a functional jump table.
5. Will break assembly tests that use multiple jump tables whose locations (jvt) are updated based on the state of the program
6. If the jvt CSR is updated, as per bullet 1, then it would cause additional new instructions (e.g. csrrw) to be inserted into a manually crafted asm file, which is usually not what one would want.

Technically, this can be avoided with `-mno-relax`-flag to the linker, but I would not expect this to be necessary, as that also leads to an impact of potentially blocking other relaxations.
That leads me to the question of what kind of scenario with tablejump-relaxation of a manually crafted assembly file would actually be useful?

I do not currently have an example on hand to reproduce this, but I will try to add that here as soon as possible. Posting this now to raise awareness of this issue.