[llvm-commits] [llvm] r164724 - in /llvm/trunk: lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp test/MC/MachO/i386-large-relocations.s

Alexander Potapenko glider at google.com
Thu Oct 18 03:24:47 PDT 2012


The following patch allows me to link my code, but I'm not sure if it
is correct to reset the type here. WDYT?

Index: lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp
===================================================================
--- lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp (revision 166174)
+++ lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp (working copy)
@@ -376,6 +376,9 @@
     // pedantic compatibility with 'as'.
     Type = A_SD->isExternal() ? (unsigned)macho::RIT_Difference :
       (unsigned)macho::RIT_Generic_LocalDifference;
+    if (FixupOffset > 0xffffff) {
+      Type = macho::RIT_Vanilla;
+    }
     Value2 = Writer->getSymbolAddress(B_SD, Layout);
     FixedValue -= Writer->getSectionAddress(B_SD->getFragment()->getParent());
   }

On Thu, Oct 18, 2012 at 1:03 PM, Alexander Potapenko <glider at google.com> wrote:
> Hi Jim,
>
> We've started to trigger exactly this fatal error (trying to emit a
> relocation with FixupOffset > 0xffffff) when compiling a large source
> file with AddressSanitizer
> (http://code.google.com/p/chromium/issues/detail?id=156005)
> Is it possible to use the macho::RIT_Vanilla relocation type for such
> cases? If it is not, are there any other workarounds except reducing
> the size of the file?
>
> On Mon, Oct 1, 2012 at 8:19 PM, Jim Grosbach <grosbach at apple.com> wrote:
>> Sweet! Thanks, Ben.
>>
>> -Jim
>>
>> On Oct 1, 2012, at 8:18 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:
>>
>>>
>>> On 01.10.2012, at 03:03, Chandler Carruth <chandlerc at google.com> wrote:
>>>
>>>> On Wed, Sep 26, 2012 at 2:27 PM, Jim Grosbach <grosbach at apple.com> wrote:
>>>> Author: grosbach
>>>> Date: Wed Sep 26 16:27:45 2012
>>>> New Revision: 164724
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=164724&view=rev
>>>> Log:
>>>> X86_32: Large Symbol+Offset relocations.
>>>>
>>>> If the offset is more than 24-bits, it won't fit in a scattered
>>>> relocation offset field, so we fall back to using a non-scattered
>>>> relocation.
>>>>
>>>> rdar://12358909
>>>>
>>>> Added:
>>>>    llvm/trunk/test/MC/MachO/i386-large-relocations.s
>>>>
>>>> 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 =/
>>>>
>>>> Is there any way to prune it down to a smaller test? Or maybe there is some N^2 aspect to this?
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>>> - Ben
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow



-- 
Alexander Potapenko
Software Engineer
Google Moscow



More information about the llvm-commits mailing list