<p dir="ltr">Out of curiosity: does this only apply to 32-bit apps (I guess no). Does the problem make LTO on Mac impossible at all, or just more complex?</p>
<div class="gmail_quote">On Oct 19, 2012 8:53 PM, "Jim Grosbach" <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Alexander,<br>
<br>
Unfortunately, that's the case. This is running into a limitation of the MachO file format and reducing the size of the file is the necessary solution.<br>
<br>
-Jim<br>
<br>
On Oct 19, 2012, at 2:10 AM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>> wrote:<br>
<br>
> Ok, I've read your IRC log and it looks like the issue can't be fixed<br>
> that easily.<br>
><br>
> On Thu, Oct 18, 2012 at 2:24 PM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>> wrote:<br>
>> The following patch allows me to link my code, but I'm not sure if it<br>
>> is correct to reset the type here. WDYT?<br>
>><br>
>> Index: lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp<br>
>> ===================================================================<br>
>> --- lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp (revision 166174)<br>
>> +++ lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp (working copy)<br>
>> @@ -376,6 +376,9 @@<br>
>>     // pedantic compatibility with 'as'.<br>
>>     Type = A_SD->isExternal() ? (unsigned)macho::RIT_Difference :<br>
>>       (unsigned)macho::RIT_Generic_LocalDifference;<br>
>> +    if (FixupOffset > 0xffffff) {<br>
>> +      Type = macho::RIT_Vanilla;<br>
>> +    }<br>
>>     Value2 = Writer->getSymbolAddress(B_SD, Layout);<br>
>>     FixedValue -= Writer->getSectionAddress(B_SD->getFragment()->getParent());<br>
>>   }<br>
>><br>
>> On Thu, Oct 18, 2012 at 1:03 PM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>> wrote:<br>
>>> Hi Jim,<br>
>>><br>
>>> We've started to trigger exactly this fatal error (trying to emit a<br>
>>> relocation with FixupOffset > 0xffffff) when compiling a large source<br>
>>> file with AddressSanitizer<br>
>>> (<a href="http://code.google.com/p/chromium/issues/detail?id=156005" target="_blank">http://code.google.com/p/chromium/issues/detail?id=156005</a>)<br>
>>> Is it possible to use the macho::RIT_Vanilla relocation type for such<br>
>>> cases? If it is not, are there any other workarounds except reducing<br>
>>> the size of the file?<br>
>>><br>
>>> On Mon, Oct 1, 2012 at 8:19 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br>
>>>> Sweet! Thanks, Ben.<br>
>>>><br>
>>>> -Jim<br>
>>>><br>
>>>> On Oct 1, 2012, at 8:18 AM, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
>>>><br>
>>>>><br>
>>>>> On 01.10.2012, at 03:03, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
>>>>><br>
>>>>>> On Wed, Sep 26, 2012 at 2:27 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br>
>>>>>> Author: grosbach<br>
>>>>>> Date: Wed Sep 26 16:27:45 2012<br>
>>>>>> New Revision: 164724<br>
>>>>>><br>
>>>>>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=164724&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=164724&view=rev</a><br>
>>>>>> Log:<br>
>>>>>> X86_32: Large Symbol+Offset relocations.<br>
>>>>>><br>
>>>>>> If the offset is more than 24-bits, it won't fit in a scattered<br>
>>>>>> relocation offset field, so we fall back to using a non-scattered<br>
>>>>>> relocation.<br>
>>>>>><br>
>>>>>> rdar://12358909<br>
>>>>>><br>
>>>>>> Added:<br>
>>>>>>   llvm/trunk/test/MC/MachO/i386-large-relocations.s<br>
>>>>>><br>
>>>>>> Jim, it looks like this is the slowest running test in the entire regression test suite now... it runs for over 30s on my system, where the total lit runtime is 52 seconds =/<br>
>>>>>><br>
>>>>>> Is there any way to prune it down to a smaller test? Or maybe there is some N^2 aspect to this?<br>
>>>>>><br>
>>>>>> The time appears to go to llvm-mc rather than macho-dump, but I've not really dug into why. I just wanted to let you know.<br>
>>>>><br>
>>>>> It just used an extremely complicated way to emit a stream of zero bytes. r164945 brings it down from 27s to 0.6s in a Debug+Asserts build.<br>
>>>>><br>
>>>>> - Ben<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> llvm-commits mailing list<br>
>>>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Alexander Potapenko<br>
>>> Software Engineer<br>
>>> Google Moscow<br>
>><br>
>><br>
>><br>
>> --<br>
>> Alexander Potapenko<br>
>> Software Engineer<br>
>> Google Moscow<br>
><br>
><br>
><br>
> --<br>
> Alexander Potapenko<br>
> Software Engineer<br>
> Google Moscow<br>
<br>
</blockquote></div>