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>