From patchwork Tue Nov 16 17:08:26 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 71435 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 1637AB7121 for ; Wed, 17 Nov 2010 04:08:57 +1100 (EST) Received: (qmail 18865 invoked by alias); 16 Nov 2010 17:08:52 -0000 Received: (qmail 18856 invoked by uid 22791); 16 Nov 2010 17:08:50 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, TW_CB, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Nov 2010 17:08:40 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 90D5DB95; Tue, 16 Nov 2010 18:08:37 +0100 (CET) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DUZIZJDkivzK; Tue, 16 Nov 2010 18:08:34 +0100 (CET) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 024B4B94; Tue, 16 Nov 2010 18:08:34 +0100 (CET) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.4+Sun/8.14.4/Submit) id oAGH8QnM005267; Tue, 16 Nov 2010 18:08:26 +0100 (MET) From: Rainer Orth To: gcc-patches@gcc.gnu.org Cc: Eric Botcazou , Ian Lance Taylor Subject: [lto, doc] Use nm -png in collect2 on Solaris 2 Date: Tue, 16 Nov 2010 18:08:26 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (usg-unix-v) MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Prompted by two reports in private mail, I've started investigating why I was seeing far fewer LTO failures on sparc-sun-solaris2.10 than they did. I've found that the problem was caused by the way collect2 looks for LTO markers (__gnu_lto_v1) in the object files linked and calls lto1 if found: * collect2 expects the output format produced by GNU nm -n and silently fails (i.e. doesn't find the markers and thus doesn't call lto1) if the format is different. This happens when Solaris nm is used, which produces the System V format by default. I've filed lto/46502 collect2 LTO marker detection is fragile wrt. to nm output format for this. * Besides, collect2 doesn't hardcode the version nm used, but does a runtime search, first for gnm, then for nm, and some other variations thereof. This is again quite fragile, since whether or not LTO works depends on the user's PATH. I believe nm should be handled like as and ld in this respect, i.e. determined at configure time and hardcode. There's lto/46503 collect2's search for nm makes LTO support fragile for this issue. To work around this issue for the moment, I've used the patch below. It turns out that NM_FLAGS can be set as required to yield the required nm output format, and nm -png works on Solaris 2 both with Sun nm and GNU nm. Unfortunately, this macro wasn't even documented so far, so I've added a short description. Bootstrapped on i386-pc-solaris2.11 without regressions (as expected, gnm was already used here), on i386-pc-solaris2.10 where it caused one regression +FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -flto -flto-partition=1to1 where lto1 hadn't been run before, but fixed two other failures: -FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1 -FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o execute -O1 -flto -flto-partition=1to1 -fwhole-program and on sparc-sun-solaris2.10 where it exposed 181 regressions. Eric already described the issue in http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00642.html but got no reply whatsoever. Would it be acceptable to deal with this in libiberty/simple-object-elf.c (simple_object_elf_attributes_compare) the same way it was done in gcc/lto/lto-elf.c (is_compatible_architecture) before, i.e. upgrade attrs1->machine to EM_SPARC32PLUS if a v8plus object file is added? It would be good to have this breakage fixed soon, given that is has existed for almost two weeks since the introduction of the simple_object_* functions. While I don't need approval for the config/sol2.h part of the patch below, I do for the documentation part. Ok for mainline? Rainer 2010-11-13 Rainer Orth * config/sol2.h (NM_FLAGS): Define. * doc/tm.texi.in (Macros for Initialization, NM_FLAGS): Document. * doc/tm.texi: Update. diff -r a21d3cbbf27e gcc/config/sol2.h --- a/gcc/config/sol2.h Sat Nov 13 16:03:04 2010 +0100 +++ b/gcc/config/sol2.h Sun Nov 14 23:13:43 2010 +0100 @@ -195,6 +195,10 @@ #undef SUPPORTS_INIT_PRIORITY #define SUPPORTS_INIT_PRIORITY 0 +/* collect2.c can only parse GNU nm -n output. Solaris nm needs -png to + produce the same format. */ +#define NM_FLAGS "-png" + #define STDC_0_IN_SYSTEM_HEADERS 1 /* diff -r a21d3cbbf27e gcc/doc/tm.texi.in --- a/gcc/doc/tm.texi.in Sat Nov 13 16:03:04 2010 +0100 +++ b/gcc/doc/tm.texi.in Sun Nov 14 23:13:43 2010 +0100 @@ -8397,16 +8397,24 @@ Define this macro as a C string constant containing the file name to use to execute @command{nm}. The default is to search the path normally for @command{nm}. +@end defmac + +@defmac NM_FLAGS +@command{collect2} calls @command{nm} to scan object files for static +constructors and destructors and LTO info. By default, @option{-n} is +passed. Define @code{NM_FLAGS} to a C string constant if other options +are needed to get the same output formut as GNU @command{nm -n} +produces. +@end defmac If your system supports shared libraries and has a program to list the dynamic dependencies of a given library or executable, you can define these macros to enable support for running initialization and termination functions in shared libraries: -@end defmac @defmac LDD_SUFFIX Define this macro to a C string constant containing the name of the program -which lists dynamic dependencies, like @command{"ldd"} under SunOS 4. +which lists dynamic dependencies, like @command{ldd} under SunOS 4. @end defmac @defmac PARSE_LDD_OUTPUT (@var{ptr})