[LLVMdev] Mach-O LTO and local relocations

Nick Kledzik kledzik at apple.com
Thu Apr 29 22:06:00 PDT 2010


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





More information about the llvm-dev mailing list