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

[Alexander Potapenko]

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?
On Oct 19, 2012 8:53 PM, "Jim Grosbach" <grosbach at apple.com> wrote:

> Hi Alexander,
>
> 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.
>
> -Jim
>
> On Oct 19, 2012, at 2:10 AM, Alexander Potapenko <glider at google.com>
> wrote:
>
> > Ok, I've read your IRC log and it looks like the issue can't be fixed
> > that easily.
> >
> > On Thu, Oct 18, 2012 at 2:24 PM, Alexander Potapenko <glider at google.com>
> wrote:
> >> 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
> >
> >
> >
> > --
> > Alexander Potapenko
> > Software Engineer
> > Google Moscow
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121019/179e10e9/attachment.html>