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
On Thu, Apr 29, 2010 at 6:19 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote:> 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.Note, llvm LTO does not use separate LTO sections. - Devang
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
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