[LLVMdev] Mach-O LTO and local relocations

[Jack Howarth]

Nick,
   Steven believes that aermod certainly could have more than 255 sections. Is there
a particular approach that would be recommended for working around such a problem?
Short of reducing the actual number of sections?
   It is suggested that this is why -ffunction-sections doesn't work on darwin
and that one possible solution is to embed an 'ar' format section in the .gnu.lto
section such the the limited object format can be avoided.
              Jack

On Thu, Apr 29, 2010 at 10:06:00PM -0700, Nick Kledzik wrote:
> This is probably a problem with having too many sections.  There are a few places where mach-o has a limit on the number of sections.  For instance the n_sect field of the nlist record is one byte.  So any symbol in a section past the 255th section wraps around and shows up with the wrong n_sect number.
> 
> -Nick
> 
> 
> On Apr 29, 2010, at 6:19 AM, Jack Howarth wrote:
> >   I am wondering how the following issue was handled for
> > libLTO? We have a working patch to implement the FSF gcc
> > LTO on darwin which now passes all of the liblto testsuite
> > but are seeing linker issues with larger programs like
> > aermod...
> > 
> > as -arch x86_64 -force_cpusubtype_ALL -o aermod.o aermod.s                
> > /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.6.3 -weak_reference_mismatches non-weak -o aermod -lcrt1.10.5.o -L./ aermod.o -lgfortran -lgcc_s.10.5 -lgcc_ext.10.5 -no_compact_unwind -lSystem -v
> > @(#)PROGRAM:ld  PROJECT:ld64-97.2
> > Library search paths:
> > 	./
> > 	/usr/lib
> > 	/usr/local/lib
> > Framework search paths:
> > 	/Library/Frameworks/
> > 	/System/Library/Frameworks/
> > ld: in aermod.o, in section __TEXT,__text reloc 17: local relocation for address 0x000FB35C in section __text does not target section __00000B26
> > 
> > When the assembly files are modified by hand, it has been found that
> > if the normal output of -flto in FSF gcc is changed from...
> > 
> > LTO sections (the __GNU_LTO stuff)
> > .text / .data / etc. (all non-LTO sections)
> > LTO __section_names section
> > 
> > ...to a re-ordered .s file of...
> > 
> > .text / .data / etc. (all non-LTO sections)
> > LTO sections (the __GNU_LTO stuff)
> > LTO __section_names section
> > 
> > ...the linker error disappears. I am asking here because it is unclear
> > how much of the Mach-O handling routines in clang were 'borrowed'
> > from gcc 4.2.1 such that a fix to this issue may already be present
> > in the llvm/clang. FYI, this problem (with a stand-alone testcase
> > to demonstrate it is in radar 7920267).
> >   Thanks in advance for any advice.
> >                 Jack
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev