[LLVMdev] Offset in MCFixup

[Matheus Almeida]

Hi,

I'm trying to implement a 10-bit relocation that does not start at the beginning of a byte-boundary and I'm not entirely sure I understand the use by some targets of MCFixup.Offset and MCFixupKindInfo.TargetOffset.

LLVM's documentation states that:

MCFixup.Offset -"/// The byte index of start of the relocation inside the encoded instruction."
MCFixupKindInfo.TargetOffset - "/// The bit offset to write the relocation into."

So if the relocation starts at bit 20 (assuming that the leftmost bit is bit number 31)  I'd say that MCFixup.Offset = 1 and MCFixupKindInfo.TargetOffset = 3
and this is somehow confirmed by the code in MCAsmStreamer::AddEncodingComment. All the relocation bits are correctly identified if I emit the encoding of an instruction.

The other use of MCFixup.Offset is in MCELFStreamer::EmitInstToData and it looks like it uses MCFixup.Offset to calculate r_offset (Elf32) which is not what I was expecting because I get a slightly skewed offset (off by MCFixup.Offset).

I can obviously create the relocation with MCFixup.Offset to be 0 (which most of the targets do) but  the code in MCAsmStreamer::AddEncodingComment will not work as expected (identification of relocation bits will be wrong) and will assert in debug builds if the relocation does not start at the beginning of a byte-boundary (and mine doesn't). I can set the size of the relocation to be the entire size of an instruction like some targets do (e.g.: ARM) but that doesn't seem to be an elegant solution.

Could someone clarify the use of MCFixup.Offset  ? At the moment I see some targets (e.g.: X86 and ARM) not bothering to set it to the value it's supposed to be (byte index of the start of the relocation) and I can only imagine it's because that information is being used by the ELF streamer class to set r_offset.

Regards,
Matheus

Matheus Almeida
MIPS processor IP
www.imgtec.com<http://www.imgtec.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130819/997337a1/attachment.html>