<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div>On Aug 19, 2013, at 5:45 AM, Matheus Almeida <<a href="mailto:Matheus.Almeida@imgtec.com">Matheus.Almeida@imgtec.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-GB" link="blue" vlink="purple" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="WordSection1" style="page: WordSection1;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Hi,<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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.<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">LLVM’s documentation states that:<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">MCFixup.Offset –“/// The byte index of start of the relocation inside the encoded instruction.”<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">MCFixupKindInfo.TargetOffset – “/// The bit offset to write the relocation into.”<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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.<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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).<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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).</div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div lang="EN-GB" link="blue" vlink="purple" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="WordSection1" style="page: WordSection1;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"> 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.<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">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.<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div></div></div></blockquote><div><br></div><div>It’s unrelated to ELF, MachO or any other object file format. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Jim</div></div></body></html>