From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30571 invoked by alias); 1 Apr 2014 18:25:26 -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 30509 invoked by uid 89); 1 Apr 2014 18:25:25 -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-f51.google.com Received: from mail-oa0-f51.google.com (HELO mail-oa0-f51.google.com) (209.85.219.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 01 Apr 2014 18:25:24 +0000 Received: by mail-oa0-f51.google.com with SMTP id i4so11666482oah.24 for ; Tue, 01 Apr 2014 11:25:22 -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=cplf9iOR14hY3cs/H0CyU6Ifd1viq8gyC8/et9AABd0=; b=BWAvn8Jd+bngGV5C5ZrqBawMJGdhMpD+gliQbk+nSJivieHYnLVtPSt0N2RWC4RbQN JpHBd53jPYIe8yxbePRiHiO2sdLdZUvQ0dVbjOFQSowLdms7iDp1khH9vqMpy3p7BgjO xVLC2yHJA/16Z60iZYc53OEw3eN3RWLi0qWol5e5PG5j85exw1ptFh++RkYf/KtY7FDC Du02ebrjvWPxTYI6uH6hcjTeEeKpKM+f2Yt8fhZ1QAvU9njwRofLMSvsnTm5DdyrdMvu FDE+C8gZvtoPh/Q/lnrxxJRw556SMZ7DsaoZQdC9rYEFjZTwDRIjWHQOJvfvzQpnFUrd 9muw== X-Gm-Message-State: ALoCoQnJterWwRfQMoOOqTApg7ocz9J7X+jBsOhukPAvW92+HbAPeL2XjJ7EA+0lIHl8eYD7ir2drodfeoTOh3TEhxJ4HSRrjTc5MX9Yd6BVygWz1Orcqv2CQYwtLZRljjJjecl9VdC5DM4WVKUSQhYkwoccE4F1C62Q44vkPRbbrDKRbXeP5LP65CMSVNvjUsy8uQse6HVwbIhYqrsteeB4yCBwsN07Cg== MIME-Version: 1.0 X-Received: by 10.60.93.168 with SMTP id cv8mr30337238oeb.21.1396376722458; Tue, 01 Apr 2014 11:25:22 -0700 (PDT) Received: by 10.60.227.226 with HTTP; Tue, 1 Apr 2014 11:25:22 -0700 (PDT) In-Reply-To: <20140331214025.E61517447E@topped-with-meat.com> 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: Tue, 01 Apr 2014 18:25: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-04/txt/msg00006.txt.bz2 On Mon, Mar 31, 2014 at 2:40 PM, Roland McGrath wrote: >> On Mon, Mar 31, 2014 at 1:04 PM, Roland McGrath wrote: >> > >> > When an input file contains a symbol pointing to a location in an >> > input section, the output file should define that symbol so it points >> > to the part of the output section that corresponds to the origin input >> > location. When the symbol points to input contents of at least one >> > byte, what this means is pretty incontrovertibly clear. In this case, >> > it points to an empty input section. But I claim that it's adequately >> > clear what it should mean in this case too. >> >> It's really not. When the eh_frame section is being optimized, there >> is no longer any correspondence between symbols defined in the input >> sections and data defined in the output section. > > I understand that's what's going on underneath. But the user didn't ask > you to fiddle with his .eh_frame contents. He did ask you to place some > symbols in his .eh_frame section. If .eh_frame optimization is not > transparent, then it's broken. The user is trying to do something special, and the linker is trying to do something special, and the two are colliding. The user is defining a symbol in one file and assuming that it will name data defined in a different file. The linker is applying special treatment to a particular section type. The two uses collide. This collision can happen in a number of different ways. For example, the same kind of thing will happen for a symbol attached to no data in a SHF_MERGE section. Or a .note.GNU-stack section. Or a .gnu.attributes section. And sections can be eliminated due to ICF. And incremental linking can change section ordering. So can GC and ICF. You are assuming that the linker is simpler than it is. In the absence of a linker script, the linker will reshuffle sections and symbols as it sees fit. It makes certain obvious guarantees. For symbols attached to no data, the kind of handling you expect is not one of them. > 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 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. In any case I think we've identified the problem and we've identified a fix. Someone just needs to implement it. Ian