From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19504 invoked by alias); 10 Sep 2014 20:56:55 -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 19486 invoked by uid 89); 10 Sep 2014 20:56:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 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-qa0-f50.google.com Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 10 Sep 2014 20:56:53 +0000 Received: by mail-qa0-f50.google.com with SMTP id cm18so17692016qab.37 for ; Wed, 10 Sep 2014 13:56:51 -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=ZZVXasjV75rchzTImWRZEPe/GJr3AXnWsAcUeWIrOow=; b=KcLKKHEyGHxDl31v39q0Rc0OIxhpRcTuKDEerkhtmdwB0I9d2JD0ldyh0+fUVfUzaC L86giPJplXc+k1yE4r4qCTiSFj5K18gvDxpoAa2RPYhX27InWW2qWG51iaR1Lh6gIwQx LgjuKkE6LrXP2eWAeEjQz+Gx25ph4QUgZAL/oR5JlELOlOzJvSuZF9B+2Z6CvqXIdHy0 AJzLkHncDTKN9wDm8KqB3nzYcJfQ+/6rZ2/J80VyallRw86VYyVvlN34vbeIbiYrQ0MU WtzpOTTRTtEOCY+ti9JeHq6kW7kI9+Jvqtrune6GkM3im7xxrDyX0fYP8TEA+9xda+oa HR/g== X-Gm-Message-State: ALoCoQlaLHJuEex3QojQa/BBoYTPEWHbnoV8ryg+xe+6a5jkJz33s7Jz62JTKwLEndaNnlzYA+Kw MIME-Version: 1.0 X-Received: by 10.224.73.132 with SMTP id q4mr19254121qaj.78.1410382611225; Wed, 10 Sep 2014 13:56:51 -0700 (PDT) Received: by 10.140.107.73 with HTTP; Wed, 10 Sep 2014 13:56:51 -0700 (PDT) In-Reply-To: References: <20140330042516.1A88E74481@topped-with-meat.com> <20140330045552.GX18201@bubble.grove.modra.org> <20140330050615.7DC5774481@topped-with-meat.com> <20140331200446.A09B074430@topped-with-meat.com> <20140331214025.E61517447E@topped-with-meat.com> Date: Wed, 10 Sep 2014 20:56:00 -0000 Message-ID: Subject: Re: gold vs libc From: Cary Coutant To: Ian Lance Taylor Cc: Roland McGrath , Alan Modra , "GNU C. Library" , Binutils , =?UTF-8?Q?Rafael_=C3=81vila_de_Esp=C3=ADndola?= Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00078.txt.bz2 Adding Rafael, since he ran into this issue again... >> IMHO it would be acceptable to simply disable .eh_frame optimization when >> there are any symbols in input .eh_frame sections that will survive to >> affect the output of anything except the .eh_frame output section's >> contents. (That tortured wording is to distinguish __EH_FRAME_BEGIN__, >> whose value is used by relocs in other sections like .text, from the >> various .L* symbols used within individual input sections that are only >> used in arithmetic producing values inside the section.) What's not >> acceptable is breaking the core semantics of linking that would apply if >> nobody had ever thought of .eh_frame optimization. > > I would say that the handling of a symbol attached to no data is not > part of the core semantics of linking. I wouldn't go that far -- it's a common-enough trick that I think it really is one of the core features. Preserving link order is important enough that we only violate that principle when explicitly told to do so (e.g., merge strings or constants, optimize sections, etc.). And in the case of optimized .eh_frame data, we actually do go to some trouble to preserve the key expectations. > I freely grant that GCC's crtbegin.o file tries this trick in a number > of different ways--even worse, crtend.o has trailing symbols. Because > of this existing behaviour, gold has various special cases to make it > continue to work. One of those special cases is for > __EH_FRAME_BEGIN__. As you've seen, the existing special case does > not work any more. This is an unfortunate interaction. I don't think > it's an obvious bug. The problem isn't so much the bracketing symbols in crtbegin.o and crtend.o. When gold optimizes the .eh_frame section, it tries to preserve the order by placing the optimized contents where the first optimizable input section appeared in the link order. Assuming that the starting symbol actually precedes the first optimizable input section, this produces the results you'd expect, and the optimized data will appear between the two bracketing symbols. When there's an optimizable input section that appears before the bracketing symbol, it's not clear to me why the linker should be expected to figure out what is really meant. Should we put the optimized data in place of the second non-empty, optimizable, input section? The third? The last? > In any case I think we've identified the problem and we've identified > a fix. Someone just needs to implement it. Have we identified a fix? From my point of view, the proper fix is to reorder the crt files so that the __EH_FRAME_BEGIN__ symbol *precedes* any non-empty .eh_frame sections. Why is this not possible? Don't we all agree that it's silly to have the start symbol follow some actual content? If you want to disable .eh_frame optimization in this case, what are the specific conditions under which we should not do it? When --eh-frame-hdr is not specified? When we're doing static linking? When we see a zero-length section with a symbol that comes after a non-zero-length section, but isn't an end bracket? (How should we tell the start bracket apart from the end bracket?) When we see a non-zero length section in a file named "crt1.o"? None of these strikes me as particularly elegant (or future-proof). If the .eh_frame data in crt1.o really does need to come before __EH_FRAME_BEGIN__, another thing you could do is simply make it so gold treats it as non-optimizable. Adding a null relocation to the first word of the section should do it; inserting a zero-length entry anywhere but the end would do it (if that doesn't have adverse affects elsewhere). -cary