This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Dec 03, 2019 at 02:26:59PM +0100, Christophe Lyon wrote:

> If I use --enable-non-contiguous-regions, link succeeds, the "one"
> section is silently discarded from the output (and no trampoline
> either).

> This is not a user-friendly behaviour :-) I'm checking how to keep the
> proper error message instead.

That's why I asked. :)

The annoying thing is that there are lots of interesting cases in that
combination, e.g. if you add


	.machine "ppc"


and try to fit that together with the other object into an output region
"one" that has two ranges of 0x20 bytes each. This would fit, by placing
the trampoline and the branch it belongs to in one range, and the four nops
in the other, but arriving at that conclusion will be difficult for the

With reversed order, it could be even worse: four nops fills half of the
first range, and either the branch or the trampoline alone would still fit,
but these need to go to the same output range as the entire point of
generating the trampoline in the first place was to have it near the
original branch.

Hypothetical adversarial memory map (not sure about syntax):

		one (RXAI) : ORIGIN = 0x00000000, LENGTH = 0x10
                one (RXAI) : ORIGIN = 0x10000000, LENGTH = 0x10
                two (RXAI) : ORIGIN = 0x20000000, LENGTH = 0x10

Getting all of these interesting cases right sounds like a lot of work to
me, and although I would expect that there might be some overlap between
"people with weird memory maps" and "people who need trampolines to get
over the holes in weird memory maps", I'm not sure that this is necessary
as long as no incorrect output is generated.

The same goes for relaxations that shrink the code, I believe Nios II has a
bunch of these as program size directly translates to resource usage. It
will be annoying if the linker refuses to link a program that would fit
after shrinking, but still acceptable to me as a user.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]