<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2016, at 10:39 AM, Rob Dalvik <<a href="mailto:rob.dalvik@gmail.com" class="">rob.dalvik@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks for the response Nick,<div class=""><br class=""></div><div class="">Do you think there is value in adding the check for FixupOffset > 0xffffff into the ARM backend? </div></div></div></blockquote><div>Yes! All the packed bit fields should be ranged checked.</div><div><br class=""></div><div>-Nick</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">The lack of that seems like it could silently record incorrect offsets from the assignment later in RecordARMScatteredRelocation():</div><div class=""><div class=""> MRE.r_word0 = ((FixupOffset << 0) |</div><div class=""> (Type << 24) |</div><div class=""> (MovtBit << 28) |</div><div class=""> (ThumbBit << 29) |</div><div class=""> (IsPCRel << 30) |</div><div class=""> MachO::R_SCATTERED);</div></div><div class=""><br class=""></div><div class="">Rob</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Dec 6, 2016 at 8:38 PM, Nick Kledzik <span dir="ltr" class=""><<a href="mailto:kledzik@apple.com" target="_blank" class="">kledzik@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2016, at 5:09 PM, Rob Dalvik <<a href="mailto:rob.dalvik@gmail.com" target="_blank" class="">rob.dalvik@gmail.com</a>> wrote:</div><br class="m_8422299165815686631Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="font-size:10pt;font-family:arial,helvetica,sans-serif" class="">CCing Nick Kledzik as <span style="font-size:10pt" class="">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" class=""><span style="font-size:10pt" class=""><br class=""></span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif" class="">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" class=""><br class=""></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif" class="">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" class=""><br class=""></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif" class="">* Should a check be added to ARMMachObjectWriter::<span style="font-size:13.3333px" class="">RecordARM<wbr class="">ScatteredRelocation and </span><span style="font-size:10pt" class="">RecordARMScatteredHalfRelo<wbr class="">cation to ensure that FixupOffset is within bounds?</span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif" class=""><span style="font-size:10pt" class=""><br class=""></span></div><div style="font-size:10pt;font-family:arial,helvetica,sans-serif" class=""><span style="font-size:10pt" class="">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" class=""><span style="font-size:10pt" class=""><br class=""></span></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px" class=""><div class=""><font face="Arial, Helvetica, sans-serif" class=""> // Relocations are written out in reverse order, so the PAIR comes first.</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> if (Type == MachO::GENERIC_RELOC_SECTDIFF ||</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> Type == MachO::GENERIC_RELOC_LOCAL_<wbr class="">SECTDIFF) {</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> // If the offset is too large to fit in a scattered relocation,</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> // we're hosed. It's an unfortunate limitation of the MachO format.</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> if (FixupOffset > 0xffffff) {</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> char Buffer[32];</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> format("0x%x", FixupOffset).print(Buffer, sizeof(Buffer));</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> Asm.getContext().reportError(<wbr class="">Fixup.getLoc(),</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> Twine("Section too large, can't encode "</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> "r_address (") + Buffer +</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> ") into 24 bits of scattered "</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> "relocation entry.");</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> return false;</font></div><div class=""><font face="Arial, Helvetica, sans-serif" class=""> }</font></div></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px" class=""><br class=""></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px" class="">* 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" class=""><br class=""></div><div style="font-family:helvetica,arial,sans-serif;font-size:13.3333px" class="">Thanks for any additional info</div></div></div></blockquote></div></span><div class="">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 class=""><br class=""></div><div class="">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" class=""><div class=""><br class=""></div><div class="">-Nick</div><div class=""><br class=""></div><div class=""><br class=""></div></font></span></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>