From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16591 invoked by alias); 31 Mar 2014 20:53:49 -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 16574 invoked by uid 89); 31 Mar 2014 20:53:48 -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-f54.google.com Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com) (209.85.219.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 31 Mar 2014 20:53:46 +0000 Received: by mail-oa0-f54.google.com with SMTP id n16so9993226oag.41 for ; Mon, 31 Mar 2014 13:53:45 -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=1Wjg/CGLJRTqrVRns45F0IuYVZ9bkaRuphbZ2zvLYVk=; b=RqHccEBxdXWRQrhD6zBRT3u0the6rDOiAlpgeMTQ6/Zc9kNbfH8+VPQEmiBCDuYWbN GW49I6933nA/66+UuIlpwL5NZNpY0MwBviXPjm46xIMAAl4trZPSrekdYlG4aheolYW/ n/l2ieVhENVs+SU2T/veptzHTgrHG74Aph9XNGmrd9s+Nc5IuNiXg83Cqb31FYU8BJwk R8l5OLvTdYZs62tl/MQtAZmMijb7HPC5KjEzyKjnOjQx7vQMhgskB3eWH+Prvzw44uVq 3kNCm0a3mUYaqz+Sc6RgAfW+4MuPVVhjyy0rKFQZoQI5uuMgKwUNfUz1K8md8V51ExM1 EYAA== X-Gm-Message-State: ALoCoQmNpkrxdoHJztqwU/U3oFo6RSb1EuES+2tatFdkGLeqfWo8NsfezP7530RZAU7K2KWaGXIrxsO7CO7JeXjQRZ6a7tp66YzV9+PiL3htplK/gKFeMmn3vX9Xd9FihDKM1xyr0on1auGnf3AsLoBtAdQmfyYMp+4xbMQD1CTJag3du3qx4SXTcu9z7tZqFQy1oolyJ0FHzxyelJfzruPvH/47rJguPw== MIME-Version: 1.0 X-Received: by 10.60.15.38 with SMTP id u6mr24943573oec.26.1396299224949; Mon, 31 Mar 2014 13:53:44 -0700 (PDT) Received: by 10.60.227.226 with HTTP; Mon, 31 Mar 2014 13:53:44 -0700 (PDT) In-Reply-To: <20140331200446.A09B074430@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> Date: Mon, 31 Mar 2014 20:53: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/msg00320.txt.bz2 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. All the input data is tossed in a heap, and the output section is constructed out of that heap. I agree that when an input symbol points to some data in some input section, and when we copy that input data unchanged, then the symbol should clearly point to the same data in the output section. That works fine for merge sections, for example. But that's not the case here. There is nothing to locate the input symbol at any location in the output section at all. The current code has a simple algorithm that usually produces the result we want: we simply copy .eh_frame sections until we find one we can optimize. Perhaps we could change to a different algorithm: put all unoptimized .eh_frame sections first, then all optimized .eh_frame sections. Ian