From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21580 invoked by alias); 2 Feb 2014 04:59:58 -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 21569 invoked by uid 89); 2 Feb 2014 04:59:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f169.google.com Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 02 Feb 2014 04:59:55 +0000 Received: by mail-ob0-f169.google.com with SMTP id wo20so6715565obc.28 for ; Sat, 01 Feb 2014 20:59:53 -0800 (PST) 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=UESMdlEfLichOvZzgV1Hx2Cm7vUB4E6O2SElrldmW+U=; b=jH3LCE2QcJYhBAhde0saWxvopO5dGukU9bGpEiMlAI9zxpOkAcFU0Ql4455NHJako2 DN2+0ZdpfarjjxHulNW45e9B9aoYccOUR4VDWensbOseZ9EVJPukO9m7pS51ZZ6Sq+bp w5kqLxix0BKno6lRsDbHCY8jB/N2fJwpBYLX2bfJShNFnOxaMqGAD9mTZsLQ5ywvUPk8 kJG0ZGOIQZBeFcBx94oWjjZhr4KzCNMLOL8IdRbQ1LIYSEdse82MDJygcJkYItcHeI+1 8flve+Ptsn55yJygLCXyD6HCpktHEkotftXrAJD2Zvz8xJjbRH8wfSL+mozBtWICxGsG ZcPA== X-Gm-Message-State: ALoCoQmaSUVAiCJMtRzwGLqkAEEs4iOff+jeoRYunAeBz+TAYCxwqC2NWS6NeOEZacKhawn4FZ4OhoT/8pdwTPxu+54nw6mivV+WlQseKX07t/3f6By7IaRXA+noz4Rvc4VrX9v7nnq4OHv2DSnvrvrTrDitfSczfhHW1K3LnR4eerOQMwUH3ysWbj7jghE60qcnKblJfYqUBPjTYRy0QKOTEY03Z6bBMQ== MIME-Version: 1.0 X-Received: by 10.60.44.8 with SMTP id a8mr4094438oem.19.1391317193752; Sat, 01 Feb 2014 20:59:53 -0800 (PST) Received: by 10.60.39.2 with HTTP; Sat, 1 Feb 2014 20:59:53 -0800 (PST) In-Reply-To: References: <10A84606-654D-4FBC-A66D-40BA39916061@gmail.com> <0263B7F5-194E-42D0-A8BB-608F0593ED61@gmail.com> Date: Sun, 02 Feb 2014 04:59:00 -0000 Message-ID: Subject: Re: gold linker: Access section start & end address w/o using a linker script From: Ian Lance Taylor To: Kevin Cc: Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00006.txt.bz2 On Sat, Feb 1, 2014 at 5:14 PM, Kevin wrote: > Ian Lance Taylor google.com> writes: > >> >> On Mon, Apr 22, 2013 at 4:39 AM, Raphael Zulliger > gmail.com> wrote: >> > >> > Is there a chance to enhance gold to better support such use cases? > Or is that out-of focus for gold? I'm not >> familiar with linking internals, but I think that providing additional > start/end address symbols for> section names starting with a '.' wouldn't > be that tricky to be added, right? >> >> I'm fine with it. Look for uses of is_cident in the gold source code. >> >> Ian >> >> > > > Thanks for the tip Ian. In that routine one could easily ignore a > leading ".". In abstract one might want to handle "." inside the > name, or translate characters (such as "$") allowed in ELF symbols but > not in C (or in some other language), whereby a simple concept starts > to get out of hand; thus: > > - Could we assume that standard ELF section names can be mapped to C > identifiers just by mapping the leading "."? > > - What mapping would you suggest? If the leading "." is dropped then > the resulting would collide with a common name (text or data in > particular). This problem seems unsolvable in general, so should one > make an effort at all (mapping "." to a single underscore for > example)? The linker doesn't define symbols that are the section names: it adds "__start_" and "__stop_" before them. I think it would be fine to just turn a leading '.' into a '_' for this purpose. Ian