From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 649 invoked by alias); 2 Jan 2012 18:38:34 -0000 Received: (qmail 640 invoked by uid 22791); 2 Jan 2012 18:38:34 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Jan 2012 18:38:20 +0000 Received: by iacb35 with SMTP id b35so32452990iac.0 for ; Mon, 02 Jan 2012 10:38:19 -0800 (PST) Received: by 10.50.161.135 with SMTP id xs7mr53776813igb.15.1325529499659; Mon, 02 Jan 2012 10:38:19 -0800 (PST) Received: by 10.50.161.135 with SMTP id xs7mr53776797igb.15.1325529499512; Mon, 02 Jan 2012 10:38:19 -0800 (PST) Received: from coign.google.com ([72.14.225.65]) by mx.google.com with ESMTPS id r5sm70784838igl.3.2012.01.02.10.38.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 10:38:18 -0800 (PST) From: Ian Lance Taylor To: John Marino Cc: binutils@sourceware.org Subject: Re: gold linker 2.22 regressed for DragonFly References: <4ED7FCA6.8090706@marino.st> <4ED88FA5.8050408@marino.st> <4EFF3AF3.3080404@marino.st> <4F017A8B.1000905@marino.st> Date: Mon, 02 Jan 2012 18:38:00 -0000 In-Reply-To: <4F017A8B.1000905@marino.st> (John Marino's message of "Mon, 02 Jan 2012 10:36:11 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00020.txt.bz2 John Marino writes: > On 1/2/2012 3:05 AM, Ian Lance Taylor wrote: >> John Marino writes: >> >>> On 12/2/2011 3:27 PM, Ian Lance Taylor wrote: >>>> John Marino writes: >>>> >>>>> I need to stress that gold built with ld does not have this problem. >>>>> It's only gold built with gold that segfaults. Does that affect your >>>>> answer? >>>> >>>> Try using the gold option --no-ctors-in-init-array. >>>> >>>> Ian >>> >>> I'm sorry that I had to put this away for a while, but I've picked it >>> back up today. >>> >>> Gold build with ld will function without segfaults and produces executables. >>> Gold build with gold segfaults. It ignores all command-line options. >>> >>> I modified the makefile to set optimization level to 0. That let me see >>> the values of variables in gdb. Using gdb on ld-new (gold built with >>> ld), "print options" on gdb shows a properly defined option set of >>> General_options class. Doing the same for ld1 (gold built by gold) >>> shows every single option with null pointers. Not even strings like >>> "Report usage information" and "Report version information" are included. >>> >>> So the problem lies in options.h within the General_options class. I >>> have no idea what ld-new is doing wrong such that ld1 can't built its >>> option set. These definitions are built with macros though. >> >> >> Did you try using the --no-ctors-in-init-array option? >> >> Ian > > Yes, I modified the gold makefile to add that to ld1_LDFLAGS and it > makes no difference. The resultant ld1 will still segfault as it tries > to build ld2. What linker are you using to build ld1? You said earlier that gold built with ld does not have a problem. Only gold build with gold segfaults. I am suggesting that you use --no-ctors-in-init-array when running gold. In fact you should try just editing options.h to make --no-ctors-in-init-array the default to see if that fixes all your problems. Otherwise, the problem you describe suggests that global constructors are not running correctly when running gold itself, but I don't know why that would happen if you are not linking gold itself with gold. Ian