[LLVMdev] Offset in MCFixup

[Jim Grosbach]

On Aug 19, 2013, at 5:45 AM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote:

> 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).

This should work fine. The non-byte offset is encoded as part of the fixup kind information (MCFixupKindInfo), which has a bit offset and size.

> 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.
>  

It’s unrelated to ELF, MachO or any other object file format. 

The byte offset is there to better support variable length encoding instruction sets like X86. It makes it easier, in theory, to handle large instructions and instructions which may have multiple fixups. Fixed width instruction sets don’t have any need for it and can just encode all of the relevant information in the MCFixupKindInfo.

Do note that the bits for a relocation are intended to be contiguous. ARM abuses this notion by having the entire instruction being considered part of the fixup. That’s a bit of a hack an should be fixed at some point. Non-contiguous sets of bits that need fixed up on an instruction should receive separate fixups.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130820/3cb53ea7/attachment.html>