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

[Christophe Lyon]

Hi,

The attached patches implement support for non-contiguous memory
regions, which was discussed in more detail in
https://sourceware.org/ml/binutils/2019-07/msg00020.html

In other words, it allows to list input sections in multiple output
regions, to help with cases were we have several memory banks, but
don't care in which one a given section goes. This avoids the painful
linker script changes needed when a memory banks become too small
after program changes (eg more data, or compiler code generation
changes).

Patch 1 contains the implementation, and patch 2 adds a new test.

This is an RFC because it lacks documentation, and I thought I should
check whether the approach is OK before polishing.

Patch 1 adds a new --enable-non-contiguous-regions linker flag which
is required to enable this new feature. Of course, we can discuss the
option name, suggestions welcome :-)
It works by allowing processing of input section multiple times until
a sufficiently large output region is found, the irrelevant ones are
removed when we detect that the candidate input section would overflow
the current output section.

At some point I thought I should insert padding when an input section
is too large to fit in the current output section, in order to make
sure it is full, but it turns out not to be necessary.

The added testcase defines 4 input sections: .data, .data.2, .data.3
and .data.4, and the linker script has
*(.data) *(.data.*)
for each of the 3 output sections .raml, .ramu and .ramz. .data.3 and
.data.3 do not fit in .raml, and are thus assigned respectively to
.ramu and .ramz.

I've run the tests with arm-none-eabi as target, and also checked that
there is no regression when forcing --enable-non-contiguous-regions:
actually only the ld/scripts/rgn-over* tests fail in such a case,
because the offending sections can be assigned to other large enough
output sections, and we no longer face the error cases these tests try
to catch.

One bit I'm not clear about in the expected results is the file offset
for .ramu and .ramz sections: why are they aligned on 0x1000, while
.ARM.attributes isn't ?

In fact, I feel my patch is surprisingly small for a feature that has
been requested for so long... :-)

Thoughts?

Thanks,

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-test-for-non-contiguous-memory.patch
Type: text/x-patch
Size: 4346 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20191129/8e9642ae/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-support-for-non-contiguous-memory.patch
Type: text/x-patch
Size: 8873 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20191129/8e9642ae/attachment-0001.bin>