From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9674 invoked by alias); 31 Mar 2014 19:03:36 -0000 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 Received: (qmail 9654 invoked by uid 89); 31 Mar 2014 19:03:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f50.google.com Received: from mail-oa0-f50.google.com (HELO mail-oa0-f50.google.com) (209.85.219.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 31 Mar 2014 19:03:33 +0000 Received: by mail-oa0-f50.google.com with SMTP id i7so9805007oag.23 for ; Mon, 31 Mar 2014 12:03:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xYpwXIwx+8m2pbP9TlU7GFwXW2cJOMCvsO6p72ox9cc=; b=Lxobr9WDs9nDG8f2UHQsEJjR7W2IizRBM0a3s+ZEvq62pNaobYE9yjpO2sHrGxPQem /6hVCyRlxu2gjHXrQtn11KufrE7aVCWUFNB8C4PuYhh7tTZ1FDMUJMWkwLYd1LUzzBDq Z0eLEo0B0/1Kr/Z8KBiZt2zfBefDggteJvGd5nO1QNRpu3bVZAJvMWx3YmeAvwBIwlUe tL/ah9bWcVOHY3bXUb8xIoMOgZVVO7uWut6GJ3f6lq1WRzM4LFSWzuT8a2m9J/Wp4h0H paAIFcQR5XZ6Q5EfkvdSGnc9TCgc48037SJatmyKeFO0j4JN7kNOfrIOS6TyIcL5IfQj vEUA== X-Gm-Message-State: ALoCoQkfhQgz8p59use/q99uF/CUZfgFaM9f3TL0I3E39ip8DObwOfU9Pf0ctKgNrRuwTcJuiDCQQxYG5H/GsW0J4HNQJPMm0pYbxFYhRGh1hqaqb30AdbVJ6bQtf3SXtbJiU514zhCOJH+57Nqm9Rqr9wWn9CJI0Q386r5t5qKoROPZ5fmO0EBahPN8rdPQ3W+YjFjBopz8HibcYIYL5sglNkL/aueopQ== MIME-Version: 1.0 X-Received: by 10.182.126.167 with SMTP id mz7mr3509505obb.69.1396292611676; Mon, 31 Mar 2014 12:03:31 -0700 (PDT) Received: by 10.60.227.226 with HTTP; Mon, 31 Mar 2014 12:03:31 -0700 (PDT) In-Reply-To: <20140330050615.7DC5774481@topped-with-meat.com> References: <20140330042516.1A88E74481@topped-with-meat.com> <20140330045552.GX18201@bubble.grove.modra.org> <20140330050615.7DC5774481@topped-with-meat.com> Date: Mon, 31 Mar 2014 19:03:00 -0000 Message-ID: Subject: Re: gold vs libc From: Ian Lance Taylor To: Roland McGrath Cc: Alan Modra , "GNU C. Library" , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00317.txt.bz2 On Sat, Mar 29, 2014 at 10:06 PM, Roland McGrath wrote: >> https://sourceware.org/bugzilla/show_bug.cgi?id=14675 > > Thanks. In fact, CFI in crt1.o is useful for the debugger (which doesn't > care where __EH_FRAME_BEGIN__ points). See: > https://sourceware.org/ml/libc-alpha/2012-03/msg00573.html > for why we added it. > > In the (more common) dynamic linking case, it works fine because > __EH_FRAME_BEGIN__ is not used. Insteaad, --eh-frame-hdr is used at link > time so PT_GNU_EH_FRAME can be used at runtime. I don't know why we don't > do it that way for static linking too. The binary-search table is a > worthwhile optimization for everybody. > > AFAICT if we just started passing --eh-frame-hdr and stopped using > crt{begin,end}T.o instead of crt{begin,end}.o under -static it would work > as is. dl_iterate_phdr in the static case should already find the > program's own phdr so libgcc can find PT_GNU_EH_FRAME in there and be happy. > > But given the status quo, gold should do something more like what ld does. I don't fully understand this, but it seems to me that gold's behaviour is correct and GNU ld's behaviour is incorrect. GNU ld is effectively discarding the exception frame information in crt1.o, and gold is retaining it. To put it another way: what principle should gold follow to get the result you want? Ian