From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22835 invoked by alias); 26 Sep 2006 16:40:30 -0000 Received: (qmail 22826 invoked by uid 22791); 26 Sep 2006 16:40:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 26 Sep 2006 16:40:28 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8QGeQdC002686; Tue, 26 Sep 2006 12:40:26 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k8QGePIW021955; Tue, 26 Sep 2006 12:40:25 -0400 Received: from [172.16.83.101] (dhcp83-101.boston.redhat.com [172.16.83.101]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k8QGePX2000985; Tue, 26 Sep 2006 12:40:25 -0400 Message-ID: <45195650.2040906@redhat.com> Date: Tue, 26 Sep 2006 16:45:00 -0000 From: Vivek Goyal Reply-To: vgoyal@redhat.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 MIME-Version: 1.0 To: "H. J. Lu" CC: Daniel Jacobowitz , binutils@sources.redhat.com Subject: Re: Linker Bug or Design Intent (Absolute symbols in zero sized sections) References: <4519350D.2090208@redhat.com> <20060926142709.GA8543@lucon.org> <4519387D.3080305@redhat.com> <20060926145159.GA8668@lucon.org> <20060926145810.GA14821@nevyn.them.org> <451941EB.3000207@redhat.com> <20060926161028.GB9105@lucon.org> <451951EC.6040709@redhat.com> <20060926163024.GA9333@lucon.org> In-Reply-To: <20060926163024.GA9333@lucon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00321.txt.bz2 H. J. Lu wrote: > On Tue, Sep 26, 2006 at 12:14:36PM -0400, Vivek Goyal wrote: > >>H. J. Lu wrote: >> >>>On Tue, Sep 26, 2006 at 11:06:19AM -0400, Vivek Goyal wrote: >>> >>> >>>>Daniel Jacobowitz wrote: >>>> >>>> >>>>>On Tue, Sep 26, 2006 at 07:51:59AM -0700, H. J. Lu wrote: >>>>> >>>>> >>>>> >>>>>>I think for --emit-relocs, we can keep an empty output section if its >>>>>>address is taken. >>>>>> >>>>>>Of course, we need to update linker doc. >>>>> >>>>> >>>>>I think we're being too specific to this case. >>>>> >>>>>Why are we changing what the linker script clearly defines as section >>>>>relative symbols to absolute symbols? This isn't the only use case >>>>>I've encountered where that will break. We should either discard the >>>>>symbols, or leave the empty section. >>>>> >>>> >>>>I think retaining the zero sized section might be more logical otherwise >>>>a user who has specifically defined a section relative symbol in linker >>>>script file will be surprised to know that in some cases symbol is not >>>>present at all. >>> >>> >>> >>>I think removing empty output sections isn't a bad idea. Otherwise, >>>a normal executable/DSO may have many empty output sections since >>>the default linker scripts may have many unused output sections. >>> >>>However, I agree that removing empty output sections shouldn't lead >>>to many surprises for user. I think linker >>> >>>1. Should remove an empty output section if it isn't used to define >>>section relative symbol which may be changed at run time. >>>2. Shouldn't convert a section relative symbol to absolute symbol >>>if it may be changed at run time. >> >>How does one determine at compile time if a section relative symbol will >>be modified or not? ("if it may be changed at run time?"). > > > How can you reasonably modify a section relative symbol at run time? > Do you need to use --emit-relocs? I need --emit-relocs as it retains the relocation information in finally linked executable and I use that relocation information to relocate the image to a different address at run time. It is just a matter of going through all the relocation entries and adding an offset value. Sorry I don't understand the first question very well. The moment a symbol is section relative and if section is moved at run time, I will be walking through and procesing all the relocations generated wrt to that symbol at run time. Thanks Vivek