https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Dominique d'Humieres from comment #4)
> > > I see the problem after having updated to Xcode 8.0. I am currently 
> > > testing
> > > the following patch
> > 
> > >  /* The .text section is generated in varasm.c  */
> > >  DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
> > > -      ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
> > > +      ".section __TEXT,__text,coalesced,pure_instructions", 0)
> > 
> > actually, we need to come up with a patch that simply emits the text/etc.
> > section whenever it would have emitted the text_coal/etc. one.. So rather
> > than adjusting section definitions - we need to change which ones are
> > selected in config/darwin.c
> > 
> > .. but this should be conditional on a new enough linker to support it, or
> > we will break support for folks on ancient systems.  Is this repeatable
> > without xcode8?
> 
> Yes, it is repeatable with Xcode 8. Someone else mentioned they duplicatd
> with it.

without xcode8 - I don't have Xcode8 installed on any system presently.

> > I have some patches in progress to detect the linker features at
> > configuration time,
> 
> be careful here. You use the new linker when -wa,-q is present. The new
> linker is the one in Clang Integrated Assembler. You use the old Apple ld
> when -Wa,-q is _not_present. Or maybe mor correctly, you just use ld.
> 
> > so that we don't need to rely on guessing from the host
> > system version. 
> 
> I _think_ you can detect which linker at runtime with something like the
> following:
> 
> IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP)
> -c "GNU assembler")
> 
> Now, ld returns the string "GNU assembler". Clang returns the string "clang:
> error: unsupported argument '--version' to option 'Wa,'".

you are conflating two things (and coming to a mixed conclusion as a result):

1. a version of the linker (ld64) that's capable of responding to the relevant
flags and operating correctly without coalesced sections to help it deal (see
the description of operation that Andrew pointed to in c #3).

2. a version of the LLVM back-end which is invoked by the cctools as
(effectively calling clang).  Which emits a warning when the section types are
emitted that are no longer needed by 1 (but, note, _are_ needed by older
linkers); the LLVM test added to gate the warning should really have been on
the target linker version, not on the arch type.

====

So .. IFF we have a ld64 which is sufficiently modern (number / feature test
TBD) we don't need to emit the old _coal sections.   If we have an old linker
(say ld64-85.2.1 since the LLVM commit discussion mentions ppc), then we need
to continue to emit the coal sections.

Essentially, the test and changes needed are to determine the linker (ld64's)
capability;

we ought not be in a position where we detect that the ld64 is too old at the
same time as trying to use the LLVM back end as the assembler.

Reply via email to