Simon,
Sounds like the instruction relocating is so complicated that ELF requires up to three relocation records to encode how to fix up one instruction. If that is the case, why not do the same and have up to three Reference objects on the same atom offset to record the same info? I thought that was model that the ELF part of lld was using - there is a one-to-one mapping of ELF reloc to lld References.
Or am I misunderstanding the issue?
-Nick
Nick,
Right now I try to implement exactly the same approach. I split a
relocation record on up to three separate relocations. But there are
two problems on this way.
The first one is how to represent some additional data provided in the
relocation record. That is why I asked the initial question in this
thread. The current solution is to extend the `Reference` class and
add one more attribute to it.
The second problem is how to handle these three relocations. Now the
`TargetRelocationHandler::applyRelocation()` method called one-by-one
for each reference. That is not applied to the MIPS N64 ABI
relocations. In that case we need to calculate the first one, save the
result, calculate the second one using result from the first step,
repeat that for the third relocations and only at the end check the
final result on overflow and apply it to the location. My current idea
is to allow a target specific code to handle the loop over atom's
references now hardcoded in the `AtomSection<ELFT>::write` method.
I definitely do not suggest to refuse the atom/reference model. My
idea is to stop considering YAML/Native formats as *union* of all
target specific properties but allow target specific code to arbitrary
extend YAML/Native formats. Like MIPS, ARM, X86 etc can extend ELF
format. That approach can be implemented by two ways. The first one is
to move real YAML/Native read/writing to the target specific code, so
lldNative and lldYAML define only common upper-level structures for
both formats and provide some common routines for reading/writing. The
second way is to allow atoms and references to keep sets of target
specific attributes in some general form like key->value dictionaries.
ARM has a concept of Group relocations, which applies relocations considering them as one set may be we should consider extending apply relocation. What do you think?
I agree with you that we should consider one of the below approaches.