What is the address problem with 68HC12 memory banks?

It is very easy to make gcc generate a CALL and use RTC. This can be driven by some option (in 68HC12 mode).

Now, the big problem is the linker which must handle the 24-bit address space. It must do so with a paging notion and an overlapping notion (of the 16K window). Today, the linker is only able to manage contiguous address space (I mean that it puts *.text code together and builds a VMA address incrementally without holes). In other words, it is able to build something that maps (loggically) to:

          0x8000   0xC000   0x10000    0x14000    0x18000
----------+--------+--------+----------+---------+------+
          |        |        |          |         |      |
----------+--------+--------+----------+---------+------+
          <------------------ text section ------------->

Some kind of address translation is necessary.

Let's say that [0x08000..0x0bfff] is page 0
	       [0x0C000..0x0ffff] is page 1
	       [0x10000..0x14000] is page 2
	       [0x14000..0x18000] is page 3   (from a GNU linker VMA point of view)

It is clear that from 68HC12 VMA point of view, when page 1 is installed, it is not at [0x0C000..0x0ffff] but really at [0x08000..0x0bfff]. But the linker does not know that and there is no easy way to tell him.

To give another example, a function can be defined at 0x10000 from GNU ld point of view. When a call to that function will be made, if there is not address translation, the call will use page 2 and 0x0000 as address. And this is not in the program bank window.