This patch modifies shouldForceRelocation to always return true for pcrel_hi and pcrel_lo fixups. This avoids having to use various levels of indirection in order to correctly determine whether a given one of these fixups can be safely resolved, since there are various situations where determining whether a given fixup can be safely resolved relies on knowing whether its corresponding fixup could be safely resolved.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
test/MC/RISCV/linker-relaxation.s | ||
---|---|---|
125 | Shouldn't be this be .Ltmp1 0x0 just like in the RELAX-RELOC case? |
test/MC/RISCV/linker-relaxation.s | ||
---|---|---|
125 | Hi Lewis, did you have any thoughts on this? |
test/MC/RISCV/linker-relaxation.s | ||
---|---|---|
125 | Yes, it should be. It's because RISCVMCExpr::evaluateAsRelocatableImpl evaluates it fully to the indirected symbol since RAB.willForceRelocations is false, unlike the RELAX-RELOC case. |
test/MC/RISCV/linker-relaxation.s | ||
---|---|---|
125 | So, if I understand correctly, evaluatePCRelLo will do it's work regardless of whether the relocation is actually evaluated, it just uses this 'best guess' function RAB.willForceRelocations and some of its own logic. Is this not a bug regardless of this patch? Are we relying on the logic in shouldForceRelocations and evaluatePCRelLo producing the exact same answer? Are there uses of evaluatePCRelLo that aren't part of this assembler pipeline? Because if not then doesn't that imply that for this patch the entire evaluatePCRelLo functionality would be completely removed? |
Shouldn't be this be .Ltmp1 0x0 just like in the RELAX-RELOC case?