Support for globals larger than 4kiB

[rmn30]

Currently the CHERIoT linkage model has a limitation that it cannot support globals larger than 4kiB. This is because instantiating pointers to globals does a sequence of auicgp, cincoffset, csetboundsimm and the set bounds instruction has a 12-bit immediate.

Some workarounds exist:

• The compiler has a workaround for globals that are used in the same compilation unit (e.g. static) by generating a longer instruction sequence using the register operand version of csetbounds but this doesn't work for globals defined in different compilation units because we don't have the correct type of relocation.
• In cheriot-rtos you can use a dynamic memory allocation, MMIO_CAPABILITY or SHARED_OBJECT

Although this hasn't been a huge issue so far we do need to fix it, especially as csetboundsimm is unlikely to be part of the riscv-cheri standard in the form we have it.

[rmn30]

For the benefit of searching the associated error message is:

relocation R_RISCV_CHERIOT_COMPARTMENT_SIZE out of range

[davidchisnall]

There are three possible approaches to fixing this:

• Add a larger code model (small vs tiny?) that emits the longer sequence and different relocs for anything it can't statically prove is smaller than 4 KiB.
• Add an attribute that can go on big globals to emit the longer sequence.
• Add a linker relaxation that turns these into loads from a captable and emits a capreloc.

I think option 2 is probably the right way to go.

[resistor]

What are the scenarios where we can't prove the size of an array statically? Just things like extern int arr[];?

Maybe it's an extreme option, but could we simply disallow uses of incompletely-typed globals in our compilation model?

[davidchisnall]

Anything extern. There are lots of cases where C allows some inconsistency. Fortran-style common linkage is the only non-static one that works, there are also fun corner cases like the magic start and stop section symbols that the linker can create.