This patch modifies the process of recording relocations and applying fixups for a fragment to allow the target to remain undecided about whether or not to force a relocation until all fixups have been evaluated.
Only after the target has been allowed to re-evaluate fixups that have been marked as unknown can the process of recording relocations and applying fixups be run.
For RISC-V, this allows us to determine exactly which %pcrel_hi and %pcrel_lo fixups need relocations by ensuring all %pcrel_lo fixups and corresponding %pcrel_hi fixups are correctly matched in this regard.
Notable changes for review:
- Changed return type of shouldForceRelocation to Optional<bool> in MCAsmBackend
- Added handleUnknownFixups to MCAsmBackend
- Split up handleFixup and evaluateFixup to handleUnresolvedFixup, evaluateFixupPreTarget and evaluateFixup
- Split up fixup handling code into two distinct passes, one to attempt to evaluate and resolve fixups, and another to report errors, record relocations, and apply fixups, with the target being allowed to intervene for unknown fixups in between the two passes
This patch is work in progress, I'd appreciate feedback on the general approach and disruptiveness of this change.
Could you make it explicit in the doc comments here that a returned value of 'None' indicates that it's indeterminate/unknown whether relocation is required.