Mach-O LTO and local relocations

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

Note, llvm LTO does not use separate LTO sections.

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

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

Yes. Put all the gnu lto stuff into one mach-o section. Within that mach-o section, you are free to subdivide it into groups however you would like.

-Nick