<div dir="ltr">Thanks for the response Nick,<div><br></div><div>Do you think there is value in adding the check for FixupOffset > 0xffffff into the ARM backend? The lack of that seems like it could silently record incorrect offsets from the assignment later in RecordARMScatteredRelocation():</div><div><div>  MRE.r_word0 = ((FixupOffset <<  0) |</div><div>                 (Type        << 24) |</div><div>                 (MovtBit     << 28) |</div><div>                 (ThumbBit    << 29) |</div><div>                 (IsPCRel     << 30) |</div><div>                 MachO::R_SCATTERED);</div></div><div><br></div><div>Rob</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 6, 2016 at 8:38 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Dec 6, 2016, at 5:09 PM, Rob Dalvik <<a href="mailto:rob.dalvik@gmail.com" target="_blank">rob.dalvik@gmail.com</a>> wrote:</div><br class="m_8422299165815686631Apple-interchange-newline"><div><div dir="ltr"><div style="font-size:10pt;font-family:arial,helvetica,sans-serif">CCing Nick Kledzik as <span style="font-size:10pt">I posed this question on IRC and Tim Northover suggested you as a good resource for this.</span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif"><span style="font-size:10pt"><br></span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif">I came across an error due to a scattered relocation offset being larger than 2**24 and I was hoping to find more information on scattered relocations. These are MachO specific, and Ive not been able to find any documentation on them outside of source code. </div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif"><br></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif">I have a couple of immediate questions, but any info would be appreciated.</div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif"><br></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif">* Should a check be added to ARMMachObjectWriter::<span style="font-size:13.3333px">RecordARM<wbr>ScatteredRelocation and </span><span style="font-size:10pt">RecordARMScatteredHalfRelo<wbr>cation to ensure that FixupOffset is within bounds?</span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif"><span style="font-size:10pt"><br></span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif"><span style="font-size:10pt">I see a check in the x86 back end that does precisely this and was curious why a similar check was not in place for ARM:</span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif"><span style="font-size:10pt"><br></span></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px"><div><font face="Arial, Helvetica, sans-serif">  // Relocations are written out in reverse order, so the PAIR comes first.</font></div><div><font face="Arial, Helvetica, sans-serif">  if (Type == MachO::GENERIC_RELOC_SECTDIFF ||</font></div><div><font face="Arial, Helvetica, sans-serif">      Type == MachO::GENERIC_RELOC_LOCAL_<wbr>SECTDIFF) {</font></div><div><font face="Arial, Helvetica, sans-serif">    // If the offset is too large to fit in a scattered relocation,</font></div><div><font face="Arial, Helvetica, sans-serif">    // we're hosed. It's an unfortunate limitation of the MachO format.</font></div><div><font face="Arial, Helvetica, sans-serif">    if (FixupOffset > 0xffffff) {</font></div><div><font face="Arial, Helvetica, sans-serif">      char Buffer[32];</font></div><div><font face="Arial, Helvetica, sans-serif">      format("0x%x", FixupOffset).print(Buffer, sizeof(Buffer));</font></div><div><font face="Arial, Helvetica, sans-serif">      Asm.getContext().reportError(<wbr>Fixup.getLoc(),</font></div><div><font face="Arial, Helvetica, sans-serif">                         Twine("Section too large, can't encode "</font></div><div><font face="Arial, Helvetica, sans-serif">                                "r_address (") + Buffer +</font></div><div><font face="Arial, Helvetica, sans-serif">                         ") into 24 bits of scattered "</font></div><div><font face="Arial, Helvetica, sans-serif">                         "relocation entry.");</font></div><div><font face="Arial, Helvetica, sans-serif">      return false;</font></div><div><font face="Arial, Helvetica, sans-serif">    }</font></div></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px"><br></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px">* Once we get here there seems to be nothing that can be done. Are there ways of avoiding generation of scattered relocations? Ive had some success in working around the problem by using llc's -relocation-model flag with 'static' and 'dynamic-no-pic' though I believe that is simply due to a small size reduction in the binary pulling the offset back into range of a 24bit value. Im also not sure that iOS will accept apps built with a static relocation model.</div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px"><br></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px">Thanks for any additional info</div></div></div></blockquote></div></span><div>Yes, 32-bit arm mach-o object files run into size limitations because of how relocations are encoded.  Some information is encoded in bits of the instruction and some is encoded in bit fields in relocations.  If you try to make an arm .o file larger than 16MB, you start hitting various limits.  Not all the limits are enforced by the MC layer, resulting in bad .o files.  </div><div><br></div><div>You could try not having debug info, or moving the __DWARF sections to the end of the file, and you might last longer.  But the only sure fix is to keep all .o file under 16MB.  The final product can be larger because resolved address are 32-bits and the linker inserts branch islands to let BL instructions branch further.  </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nick</div><div><br></div><div><br></div></font></span></div></blockquote></div><br></div>