[LLVMdev] Mach-O LTO and local relocations

[Nick Kledzik]

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

On Apr 30, 2010, at 6:48 AM, Jack Howarth wrote:
> 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