Bug 66523 - the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m
Summary: the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 5.1.0
: P2 major
Target Milestone: 5.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-12 15:05 UTC by Jack Howarth
Modified: 2015-07-09 19:28 UTC (History)
5 users (show)

See Also:
Host: x86_64-apple-darwin1[4,5]
Target: x86_64-apple-darwin1[4,5]
Build: x86_64-apple-darwin1[4,5]
Known to work: 4.9.4, 5.1.1, 5.2.0, 6.0
Known to fail: 4.9.3, 5.1.0
Last reconfirmed: 2015-07-07 00:00:00


Attachments
proposed fix from Iain Sandoe (573 bytes, text/plain)
2015-06-12 15:05 UTC, Jack Howarth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2015-06-12 15:05:23 UTC
Created attachment 35773 [details]
proposed fix from Iain Sandoe

The new clang-based assembler in Xcode 7 fails to build libobjc in FSF gcc 5.1 with the following error...

/bin/sh ./libtool  --mode=compile /sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/ -B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/bin/ -B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/lib/ -isystem /sw/lib/gcc5/x86_64-apple-darwin15.0.0/include -isystem /sw/lib/gcc5/x86_64-apple-darwin15.0.0/sys-include    /sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/NXConstStr.m -c \
	   -I. -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc   -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc/config -I../.././gcc -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../libgcc -I../libgcc -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../include  -fgnu-runtime \
	   -o NXConstStr.lo
libtool: compile:  /sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/ -B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/bin/ -B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/lib/ -isystem /sw/lib/gcc5/x86_64-apple-darwin15.0.0/include -isystem /sw/lib/gcc5/x86_64-apple-darwin15.0.0/sys-include /sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/NXConstStr.m -c -I. -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc/config -I../.././gcc -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../libgcc -I../libgcc -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../include -fgnu-runtime  -fno-common -DPIC -o .libs/NXConstStr.o
/var/tmp//ccc9efWx.s:98:17: error: non-local symbol required in directive
        .no_dead_strip L_OBJC_Module
                       ^
make: *** [NXConstStr.lo] Error 1

The proposed patch from Iain Sandoe suppresses this assembler error and allows libobjc to build under the clang-based assembler.
Comment 1 Jack Howarth 2015-06-12 15:11:31 UTC
Previously filed as radr://21323034, "the new clang-based assembler in Xcode 7 on 10.11 fails on the NXConstStr.s file from FSF gcc 5.1"
Comment 2 kassafari 2015-06-15 15:00:51 UTC
status check
Comment 3 Iain Sandoe 2015-06-15 15:09:46 UTC
(In reply to kassafari from comment #2)
> status check

you can use the patch in the short-term, but I want to check for other solutions too.
Comment 4 Jack Howarth 2015-06-19 23:36:33 UTC
FYI, Apple's response on radar was...

This is correct behavior from the assembler. The GNU objc runtime is doing bad things here by assuming an assembler local symbol (any symbol starting with “L”) is not, in fact, assembler local and will instead live on for the linker to see. We advise you don’t do that.
Comment 5 Jack Howarth 2015-07-01 14:04:04 UTC
This is the last remaining issue with building gcc trunk using the clang-based assembler in Xcode 7. Should we check in Iain's proposed fix for now as a stop-gap fix>
Comment 6 mrs@gcc.gnu.org 2015-07-05 18:10:55 UTC
Another proposal, any symbol with an 'L.*' spelling should be not so marked, as these can never be used this way.  Seems like we should have a predicate to call before marking something as no dead strip and it should get rid of all of them, including L.* symbols.
Comment 7 Iain Sandoe 2015-07-05 18:39:42 UTC
(In reply to mrs@gcc.gnu.org from comment #6)
> Another proposal, any symbol with an 'L.*' spelling should be not so marked,
> as these can never be used this way.  Seems like we should have a predicate
> to call before marking something as no dead strip and it should get rid of
> all of them, including L.* symbols.

that's pretty much what my comment says - however, what I want to check (when I get a spare ns) is whether ObjC should be emitting "l_xxx" symbols for these (i.e. linker-only-visible, but not preserved).  If someone else has time to look before me, then fine :)
Comment 8 Iain Sandoe 2015-07-07 07:50:36 UTC
(In reply to Iain Sandoe from comment #7)
> (In reply to mrs@gcc.gnu.org from comment #6)
> > Another proposal, any symbol with an 'L.*' spelling should be not so marked,
> > as these can never be used this way.  Seems like we should have a predicate
> > to call before marking something as no dead strip and it should get rid of
> > all of them, including L.* symbols.
> 
> that's pretty much what my comment says - however, what I want to check
> (when I get a spare ns) is whether ObjC should be emitting "l_xxx" symbols
> for these (i.e. linker-only-visible, but not preserved).  If someone else
> has time to look before me, then fine :)

So, I had a look at what Apple gcc-4.2.1 and current TOT clang produce.
gcc-4.2.1 is silent about preservation.
clang puts the relevant stuff into sections marked as "no_dead_strip" (but doesn't mark the individual symbols).

For LTO to work we need to mark these items as non-strippable, because that happens in a way that won't see that the containing section is "no_dead_strip".

Thus, for now, I think that the patch I have in my Q is OK.

(as a follow-on, I think to revise the section headers to ensure that they contain "no_dead_strip", but that needs to be checked to be compatible with the range of ld64 variants we use).

The current patch does what Mike has suggested above - rejects symbols starting with L* as no_dead_strip.

Any other opinions (or shall I post/apply the patch)?
Comment 9 mrs@gcc.gnu.org 2015-07-07 16:02:28 UTC
Ok.  Ok for all active release branches.
Comment 10 Jack Howarth 2015-07-07 18:57:21 UTC
I assume we have missed the window for gcc 5.2.0.
Comment 11 mrs@gcc.gnu.org 2015-07-07 19:04:03 UTC
No, but one has to get RM approval.  Should be easy enough to get that, as long as the work gets done before they make the last snapshot.

Does someone have the regression test done on the release branch (and trunk)?  Does it look good on both?  If so, I can ask them RM if I can drop it in.
Comment 12 Jack Howarth 2015-07-08 15:13:33 UTC
Regression testing of gcc-5.2.0-RC-20150707 with https://gcc.gnu.org/bugzilla/attachment.cgi?id=35773 applied posted at...

https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00825.html

showing no regressions compared to the previous results for gcc 5.1.1 without the proposed fix applied...

https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00300.html
Comment 13 mrs@gcc.gnu.org 2015-07-08 16:57:17 UTC
Author: mrs
Date: Wed Jul  8 16:56:46 2015
New Revision: 225565

URL: https://gcc.gnu.org/viewcvs?rev=225565&root=gcc&view=rev
Log:
2015-07-08  Iain Sandoe  <iain@codesourcery.com>

	PR target/66523
	* config/darwin.c (darwin_mark_decl_preserved): Exclude 'L' label names from
	preservation.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin.c
Comment 14 mrs@gcc.gnu.org 2015-07-08 17:00:17 UTC
Fixed in trunk, awaiting RM approval for gcc 5.
Comment 15 mrs@gcc.gnu.org 2015-07-08 17:20:22 UTC
Jack, can you spin a gcc-4.9 test?
Comment 16 Jack Howarth 2015-07-09 02:15:30 UTC
Regression testing of gcc trunk with fix posted at https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00873.html
Comment 17 Jack Howarth 2015-07-09 16:08:06 UTC
Any response on the request for RM approval for adding this to 5.2.0?
Comment 18 mrs@gcc.gnu.org 2015-07-09 17:51:30 UTC
Author: mrs
Date: Thu Jul  9 17:50:58 2015
New Revision: 225623

URL: https://gcc.gnu.org/viewcvs?rev=225623&root=gcc&view=rev
Log:
2015-07-09  Iain Sandoe  <iain@codesourcery.com>

	PR target/66523
	* config/darwin.c (darwin_mark_decl_preserved): Exclude 'L' label names from
	preservation.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/darwin.c
Comment 19 mrs@gcc.gnu.org 2015-07-09 17:56:54 UTC
Author: mrs
Date: Thu Jul  9 17:56:23 2015
New Revision: 225624

URL: https://gcc.gnu.org/viewcvs?rev=225624&root=gcc&view=rev
Log:
2015-07-09  Iain Sandoe  <iain@codesourcery.com>

	PR target/66523
	* config/darwin.c (darwin_mark_decl_preserved): Exclude 'L' label names from
	preservation.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/darwin.c
Comment 20 mrs@gcc.gnu.org 2015-07-09 18:00:09 UTC
Fixed.
Comment 21 Jack Howarth 2015-07-09 19:28:30 UTC
(In reply to mrs@gcc.gnu.org from comment #15)
> Jack, can you spin a gcc-4.9 test?

Regression test results for current gcc-4_9-branch with patch applied posted at https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00953.html