[LLVMdev] Mach-O LTO and local relocations

[Jack Howarth]

   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