On Sat, Mar 12, 2011 at 09:34:01PM -0800, Chris Lattner wrote:
>
> On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote:
>
> > With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made
> > to
> > the darwin assembler which effectively breaks LTO support for darwin. The
> > design
> > of LTO on darwin was based on the fact that mach-o object files tolerated
> > additional
> > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the
> > assembler
> > appears to be strictly counting sections and objecting when these exceed
> > 255. This
> > breaks huge sections of the lto testsuite and prevents larger projects like
> > xplor-nih
> > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple
> > reverts this
> > change, our only recourse would be to resort to an elf object container for
> > the lto
> > sections within the mach-o files (introducing an undesired dependency on
> > libelf for
> > FSF gcc on darwin). My understanding was that the lto design did not allow
> > the number
> > of sections required in the lto files to be reduced.
>
> Hi Jack,
>
> Please file a bug against the apple bug tracker explaining exactly what you
> need to work with some example .o files.
>
> -Chris
Chris,
I have already opened Problem ID: 9126174 on radar and uploaded the
builtin-attr-1.s assembly file
from the failed...
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c
-O2 -flto -flto-partition=none -ffast-math -lm --save-temps -v -m32 -o
builtin-attr-1.exe
linkage. The failure occurs as...
builtin-attr-1.s:12528:FATAL:too many sections (maximum 255)
when 'as -arch i386 -force_cpusubtype_ALL -o builtin-attr-1.o builtin-attr-1.s'
is executed.
This same assembly file works fine with 'as' from Xcode 3.2.5. Also the 12528th
line happens
to be just after the 253rd GNU_LTO section which makes sense as there is a
__TEXT,__text_startup
and __TEXT,__eh_frame section as well. If I truncate the assembly file at 253
GNU_LTO sections
it is assembled without complaint. Nick believed that the assembler was looking
for symbols in
each section and verifying the section count that way. I don't believe that is
true and that a simple
count of all sections is being done instead. If true, it prohibits us from
using the current approach
of placing all of the GNU_LTO sections at the end of the assembly. Since they
don't contain symbols
this has never been a problem in the past.
Jack
