[PATCH RFC v2] Add support for non-contiguous memory regions

Christophe Lyon christophe.lyon@linaro.org
Wed Jan 29 21:28:00 GMT 2020


On Mon, 13 Jan 2020 at 17:24, Christophe Lyon
<christophe.lyon@linaro.org> wrote:
>
> On Mon, 13 Jan 2020 at 15:37, Simon Richter <Simon.Richter@hogyros.de> wrote:
> >
> > Hi,
> >
> > sorry, overlooked the original email.
> >
> > > > > Wait, this option means that if an input section is listed multiple times,
> > > > > it isn't duplicated like it used to be?
> >
> > > > > That might be a problem for people who are building overlays for banked
> > > > > memory, or to conserve RAM.
> >
> > > > I haven't checked that. Is there an existing testcase?
> >
> > > I should probably have phrased that differently: I ran the testsuite
> > > for arm and powerpc, no regression.
> > > Do you have a case in mind that is not covered by the existing testsuite?
> >
> > Did you run the testsuite with --enable-non-contiguous-regions? If so, that
> Yes, but after I sent my previous email.... and it shows a few
> regressions, which I'm looking at.

I have patches for the problems I noticed (took me a while to realize
that my new option is incompatible with "INSERT", since it can change
the input section -> output section mapping).

>
> However the *overlay* tests under ld-elf still work.
>
> > looks like a gap in test coverage to me, e.g. I'd fully expect to be able
> > to do something like
> >
> > trampoline.S:
> >
> >         .section .text.trampoline
> >         stmdb sp, {r10}
> >         ldr r10, =BANK_SWITCH
> >         str r11, [r10]
> >         ldmia sp, {r10}
> >         nop
> >         nop
> >         nop
> >         nop
> >         nop
> >         b r11
> >
> > and then reuse that section on every bank:
> >
> >         SECTIONS {
> >                 .bank0 0x0 : {
> >                         *(.text.trampoline)
> >                         *(.text.bank0)
> >                 } >BANK0
> >                 .bank1 0x10000 : {
> >                         *(.text.trampoline)
> >                         *(.text.bank1)
> >                 } >BANK1
> >         }
> >
> > in order to generate binary images that contain the repeated parts for all
> > memory banks.
> >

What did you actually mean earlier by "Wait, this option means that if
an input section is listed multiple times,
it isn't duplicated like it used to be?"
In which cases are sections duplicated (when you say "used to be")? My
understanding is that input section have only one output section.

Thanks,

Christophe


> > The official method
> >
> >         SECTIONS {
> >                 .text.trampoline : {
> >                         *(.text.trampoline)
> >                 }
> >                 OVERLAY : {
> >                         .bank0 : {
> >                                 *(.text.bank0)
> >                         }
> >                         .bank1 : {
> >                                 *(.text.bank1)
> >                         }
> >                 }
> >         }
> >
> > is a lot less useful for generating images ready for programming, because
> > it assumes that we are building a single image that a loader will pull into
> > RAM piecewise.
> >
> > I'm certain there are other use cases for repeated sections as well, bank
> > switching is more of a thing on smaller CPUs like the 8051, which have
> > interrupt trampolines on every bank because the interrupt handling logic
> > does not know about the memory map[1].
> >
> > As usual, I'm only looking for possible problems here, with an emphasis on
> > "possible" -- whether these are relevant from a project management POV is
> > up to the actual project maintainers.
> >
> > As a user, it'd be awesome to be able to use the combination of
> > non-contiguous regions, banking with a trampoline and linker relaxations to
> > automatically distribute code over multiple banks and generate the most
> > efficient jump instructions between them, but that would be a rather
> > monumental task.
> >
> >    Simon
> >
> > [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka8894.html



More information about the Binutils mailing list