From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73260 invoked by alias); 2 Jul 2019 06:49:14 -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 69351 invoked by uid 89); 2 Jul 2019 06:49:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_RP_RNBL,SPF_PASS autolearn=no version=3.3.1 spammy=correspondence, 270619, 27.06.19, flowing X-HELO: ipmail06.adl6.internode.on.net Received: from ipmail06.adl6.internode.on.net (HELO ipmail06.adl6.internode.on.net) (150.101.137.145) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jul 2019 06:49:01 +0000 Received: from ppp118-209-76-203.bras1.mel11.internode.on.net (HELO ratatosk) ([118.209.76.203]) by ipmail06.adl6.internode.on.net with ESMTP; 02 Jul 2019 16:18:58 +0930 Received: by ratatosk (Postfix, from userid 1000) id 8F8272391; Tue, 2 Jul 2019 16:48:57 +1000 (AEST) Date: Tue, 02 Jul 2019 06:49:00 -0000 From: Erik Christiansen To: Christophe Lyon Cc: Tejas Belagod , binutils , Maxim Kuvyrkov , Peter Smith Subject: Re: [RFC] Allow linker scripts to specify multiple output regions for an output section? Message-ID: <20190702064857.GA3414@ratatosk> Mail-Followup-To: Christophe Lyon , Tejas Belagod , binutils , Maxim Kuvyrkov , Peter Smith References: <20170309120639.GF3472@ratatosk> <593A92AB.6020609@foss.arm.com> <20170609133536.GA3343@ratatosk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00020.txt.bz2 On 27.06.19 14:58, Christophe Lyon wrote: > On Fri, 9 Jun 2017 at 15:35, Erik Christiansen wrote: > > On 09.06.17 13:20, Tejas Belagod wrote: > > > > > I agree that replacing the first-match rule with a subsequent match rule > > > > > controlled by a command-line switch is much much lower implementation cost. > > > > > It will be interesting to hear views of a maintainer about the preferred > > > > > approach. > > ... > We have received requests to support non-contiguous memory regions in > the BFD linker, so it seems it is time to resurrect this thread :-) > > IIUC, Erik made a proposal that seems simpler to implement than the > initial one in > https://sourceware.org/ml/binutils/2017-03/msg00020.html > > Tejas, on your side, do you have any news about this project? (ideally > in terms of implementation, but updated specs would be good too) Having not heard from Tejas or Thomas since the on-list posts in 2017, the closest I can offer to draft specs is a summary of my recollection of the consensus reached: A memory region with a hole is identical to two non-contiguous memory regions, if flowing of input sections preempts the linker's existing overflow detection. Existing linker script syntax can specify the regions, but the flowing is currently lacking. Flowing should occur when the remaining space in a region cannot accommodate the next full input section about to be allocated, and the current input section matches a pattern in a subsequent output section, directed to another memory region. The comparison is (LENGTH - SIZEOF) vs input section size, as we have a 1:1 correspondence between output section and memory region for flow steering, anyway.) Flowing granularity is full input sections. That avoids needing to rework relocations within an input section, due to flowing. Care may need to be taken to still invoke existing linker code to provide (default or explicit) FILL to the memory remnant. (I.e. slip it in before resuming allocation in the next region.) A command line switch would usefully protect against any backward linker script incompatibility. A new refinement?: The required search for a second pattern match might be more simply implemented by remembering the output section in which the first match was found, and when needing a second match, resuming the search from the following output section. When available subsequent matches are exhausted, the existing overflow detection is finally reached, giving consistent behaviour. The simplified implementation does not require modification of linker script syntax. It also allows explicit placement of chosen input sections in a preferred memory section. In addition to simple flowing of *(.data) *(.data.*): MEMORY { RAML (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000 RAMU (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00040000 RAMZ (rwx) : ORIGIN = 0x20040000, LENGTH = 0x00040000 } SECTIONS { .raml : AT ( ADDR (.text) + SIZEOF (.text) ) { _rmal_start = . ; *(.boot) ; *(.data) *(.data.*) ; _raml_end = . ; } > RAML .ramu : AT ( ADDR (.raml) + SIZEOF (.raml) ) { _rmau_start = . ; *(.data) *(.data.*) ; _ramu_end = . ; } > RAMU .ramz : AT ( ADDR (.ramu) + SIZEOF (.ramu) ) { _rmaz_start = . ; *(.data) *(.data.*) ; version.data _ramz_end = . ; } > RAMZ } additional patterns can be specified to allocate key input sections in a specific memory region. Such control would not be achievable with a new syntax ">RAML,RAMU,RAMZ" implementation. It's not a very detailed "spec", but it's the strategy to date. (Barring anything that I've forgotten.) It would be interesting to hear how well that matches your use case, as this is the time to wrangle any wrinkles, while maintaining existing user flexibility. Erik