Avoiding relocation offsets

I’m currently working on modifying the shared C library so that when a client registers, if there are multiple versions of a routine available (e.g. software vs. hardware division) the client’s stubs will link directly to the version that’s most appropriate for the machine. Part of this involves modifying the way CLib stores the list of routines that are to be exported to the client (it’s just a list of entries produced using the Entry macro) so that each entry can either be a direct pointer to a function or a pointer to a “variant table” which describes which variants (versions) of a particular routine exist and when to use them.

Because each build of CLib is optimised according to the CPU architecture(s) that it targets, it makes sense to only generate variants for the situations where they’ll be needed. But building that selection logic into the Entry macro would be messy – it’s too far away from the location where the actual code is, and the two locations could easily get out of sync. So to solve this I thought I’d try using some pointer hackery – if it’s a regular routine the symbol that the Entry macro generates a reference to will be word aligned. If it’s a variant table then it won’t be word aligned (this also requires the Entry macro to use e.g. _kernel_udiv$variant as the symbol to import rather than _kernel_udiv – so that code internal to CLib can continue to call the old function as normal (and for the time being, the old function will be cater to the lowest-common-denominator CPU architecture). For the cases where variants aren’t required the macro that’s used to generate the variant table will just make _kernel_udiv$variant an alias of _kernel_udiv, making the actual implementation of Entry agnostic of whether variants are currently in use or not).

To allow Entry to store unaligned addresses I’ve had to change it from using “B $Temps” to generate the reference to using “DCD $Temps - .”. But therein lies the problem – even though DCD is generating an offset, the DCD is still put into the list of values that need fixing up by __RelocCode. For ROM builds everything is fine, but for RAM builds the relative offset to the symbols suddenly become absolute addresses once the module has been loaded.

This is almost certainly a bug in the toolchain, but before I give up and go with a different approach I was wondering if anyone knew of a way of generating an unaligned address offset which doesn’t trigger a relocation at runtime. I’ve tried BLX (linker doesn’t support that type of relocation), and I’ve tried “DCD $Temps - some_other_symbol” (if some_other_symbol is within the same area, it fails in the same way. If some_other_symbol is in a different area, it complains about the expression/relocation not being supported). Possibly “DCD $Temps - some_area_name” will work, as that’s the approach that many modules seem to use for generating the offsets contained in the module header – I just have to find a suitable area name to use (there are multiple tables of exported routines, in different areas, and the variant tables contain address offsets as well, so ideally I’d want to use the same area name/base address across all locations)