Big endian support in binutils

[zeldin]

This should probably not be merged into riscv-binutils-2.35 as I suppose that is an upstreams tracking branch. But maybe a new branch alongside riscv-binutils-2.35-rvb? My goal here is to get more visibility for the patchset so that people who need it can find it more easily, and maybe even get some comments on it. :smile:

Of note here is the function perform_relocation which contains a heuristic for determining if a relocation is against data (which has natural byte ordering, i.e. bfd_get/bfd_put should be used), or instructions (which may have unnatural byte ordering, and so require different load/store functions). The heuristic is that any multi-byte relocation which updates with a mask must be an instruction. This is similar to what aarch64 (which has the same problem) does in _bfd_aarch64_elf_put_addend, although aarch64 can restrict the instruction case to 32-bit relocations only as they have a fixed instruction length.

[jim-wilson]

Patches for binutils require FSF copyright assignments, and it is hard to track assigments in a github riscv tree as there is no easy way to figure out who anyone is or who they work for. I would prefer to have branches in the upstream tree. Yes, we have B and V patches in the github riscv tree, but I want to "fix" that by moving them upstream, and don't want any new development branches here. I'd also like to eliminate the repos here and make riscv-gnu-toolchain use the upstream trees directly instead of github riscv copies of them. These github riscv repos are causing problems.

The B and V extensions are still in draft, but big-endian support is already part of the ISA, so these patches don't need the same special treatment. You may need psABI changes if you need a new elf header flag or need to change the definition of a reloc. That stuff would have to be discussed with the psABI committee.

I don't see an obvious copyright assignment for you. If you are serious about doing GNU binutils work, you should try to get the assignment first, as this can take some time, depending on who you work for. You can start the process by sending email to assign@gnu.org and mention what projects(s) you want to contribute to.

[zeldin]

@jim-wilson I can do that. I just don't want to submit something directly to GNU before discussing it here first.

I don't believe any new ELF flags will be needed; ELF already has a perfectly good endianness flag. :smile:

[kito-cheng]

Just one minor comment, I would prefer the triple names are riscvbe,riscv32be and riscv64be* :P

[zeldin]

@kito-cheng Ok. I borrowed the _be suffix from aarch64, which has many similarities to RV64, but there is no real standard here and personally I'm fine with either.

[Nelson1225]

Thanks for implementing this, these are LGTM.

[Nelson1225]

This is already included in the upstream, so I close it unless there are other new problems happen. Thanks for all.