public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Christophe Lyon <christophe.lyon@linaro.org>,
	Tejas Belagod <Tejas.Belagod@arm.com>,
	binutils <binutils@sourceware.org>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	Peter Smith <peter.smith@linaro.org>,
	Alan Modra <amodra@gmail.com>
Subject: Re: [RFC] Allow linker scripts to specify multiple output regions for an output section?
Date: Wed, 24 Jul 2019 07:28:00 -0000	[thread overview]
Message-ID: <9fcd5897-56ab-7653-900d-ea89a674de39@redhat.com> (raw)
In-Reply-To: <CAKdteOZ4k1XrQ97GX4hhiK0xS=fA75Wv1bUUVhW0dcPjP26Z8A@mail.gmail.com>

Hi Christophe,

>> 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.*):

>> 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

> What do maintainers think about this? Would it be acceptable?

Yes, but you need to be very careful about what happens when switching
from one output section to another.  Can the linker backtrack to an 
earlier output section if it subsequently finds an input section which
will fit in the remaining space ?

If you do allow backtracking then the ordering of sections can change
from the current linker's specified behaviour (sections are linked in
input order unless a SORT keyword is used).  And so users will complain.
If you don't allow backtracking then there could be gaps in memory
regions which could have been used, and users will complain... :-)

Cheers
  Nick

  reply	other threads:[~2019-07-24  7:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 12:06 Erik Christiansen
2017-06-09 12:21 ` Tejas Belagod
2017-06-09 13:35   ` Erik Christiansen
2019-06-27 12:58     ` Christophe Lyon
2019-07-02  6:49       ` Erik Christiansen
2019-07-11  8:42         ` Christophe Lyon
2019-07-24  7:28           ` Nick Clifton [this message]
2019-07-24  9:18             ` Simon Richter
2019-07-24 12:48               ` Erik Christiansen
  -- strict thread matches above, loose matches on Subject: below --
2017-02-22 15:28 Thomas Preudhomme
2017-02-27 10:27 ` Tejas Belagod
2017-02-28  5:52 ` Erik Christiansen
2017-02-28 12:11   ` Tejas Belagod
2017-03-01  7:12     ` Erik Christiansen
2017-03-02  4:32 ` Erik Christiansen
     [not found]   ` <58B83CDA.5050000@foss.arm.com>
2017-03-03 10:27     ` Erik Christiansen
2017-03-07 11:06       ` Tejas Belagod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9fcd5897-56ab-7653-900d-ea89a674de39@redhat.com \
    --to=nickc@redhat.com \
    --cc=Tejas.Belagod@arm.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=christophe.lyon@linaro.org \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=peter.smith@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).