[POWERPC] Fix bootwrapper builds with newer gcc versions

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.

To workaround this issue, we just stole the save/restore code from gcc
and simplified it down for our needs (integer only).

Signed-off-by: Kumar Gala <redacted>
---
 arch/powerpc/boot/Makefile    |    2 +-
 arch/powerpc/boot/crtsavres.S |  125 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 126 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/crtsavres.S

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7822d25..77645a3 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile

@@ -51,7 +51,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.o main.o): \
 	$(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix $(obj)/,$(zlibheader))

 src-libfdt := fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
-src-wlib := string.S crt0.S stdio.c main.c \
+src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
 		$(addprefix libfdt/,$(src-libfdt)) libfdt-wrapper.c \
 		ns16550.c serial.c simple_alloc.c div64.S util.S \
 		gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \

diff --git a/arch/powerpc/boot/crtsavres.S b/arch/powerpc/boot/crtsavres.S
new file mode 100644
index 0000000..614f3c4
--- /dev/null
+++ b/arch/powerpc/boot/crtsavres.S

@@ -0,0 +1,125 @@
+/*
+ * Special support for eabi and SVR4
+ *
+ *   Copyright (C) 1995, 1996, 1998, 2000, 2001 Free Software Foundation, Inc.
+ *   Written By Michael Meissner
+ *   64-bit support written by David Edelsohn
+ *
+ * This file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file with other programs, and to distribute
+ * those programs without any restriction coming from the use of this
+ * file.  (The General Public License restrictions do apply in other
+ * respects; for example, they cover modification of the file, and
+ * distribution when not linked into another program.)
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, write to
+ * the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+ *
+ *    As a special exception, if you link this library with files
+ *    compiled with GCC to produce an executable, this does not cause
+ *    the resulting executable to be covered by the GNU General Public License.
+ *    This exception does not however invalidate any other reasons why
+ *    the executable file might be covered by the GNU General Public License.
+ */
+
+/* Do any initializations needed for the eabi environment */
+
+	.file	"crtsavres.S"
+	.section ".text"
+
+/* On PowerPC64 Linux, these functions are provided by the linker.  */
+#ifndef __powerpc64__
+
+#define FUNC_START(name) \
+	.type name,@function; \
+	.globl name; \
+name:
+
+/* Routines for saving integer registers, called by the compiler.  */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer save area.  */
+
+FUNC_START(_savegpr_14)	stw	14,-72(11)	/* save gp registers */
+FUNC_START(_savegpr_15)	stw	15,-68(11)
+FUNC_START(_savegpr_16)	stw	16,-64(11)
+FUNC_START(_savegpr_17)	stw	17,-60(11)
+FUNC_START(_savegpr_18)	stw	18,-56(11)
+FUNC_START(_savegpr_19)	stw	19,-52(11)
+FUNC_START(_savegpr_20)	stw	20,-48(11)
+FUNC_START(_savegpr_21)	stw	21,-44(11)
+FUNC_START(_savegpr_22)	stw	22,-40(11)
+FUNC_START(_savegpr_23)	stw	23,-36(11)
+FUNC_START(_savegpr_24)	stw	24,-32(11)
+FUNC_START(_savegpr_25)	stw	25,-28(11)
+FUNC_START(_savegpr_26)	stw	26,-24(11)
+FUNC_START(_savegpr_27)	stw	27,-20(11)
+FUNC_START(_savegpr_28)	stw	28,-16(11)
+FUNC_START(_savegpr_29)	stw	29,-12(11)
+FUNC_START(_savegpr_30)	stw	30,-8(11)
+FUNC_START(_savegpr_31)	stw	31,-4(11)
+			blr
+
+/* Routines for restoring integer registers, called by the compiler.  */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area.  */
+
+FUNC_START(_restgpr_14)	lwz	14,-72(11)	/* restore gp registers */
+FUNC_START(_restgpr_15)	lwz	15,-68(11)
+FUNC_START(_restgpr_16)	lwz	16,-64(11)
+FUNC_START(_restgpr_17)	lwz	17,-60(11)
+FUNC_START(_restgpr_18)	lwz	18,-56(11)
+FUNC_START(_restgpr_19)	lwz	19,-52(11)
+FUNC_START(_restgpr_20)	lwz	20,-48(11)
+FUNC_START(_restgpr_21)	lwz	21,-44(11)
+FUNC_START(_restgpr_22)	lwz	22,-40(11)
+FUNC_START(_restgpr_23)	lwz	23,-36(11)
+FUNC_START(_restgpr_24)	lwz	24,-32(11)
+FUNC_START(_restgpr_25)	lwz	25,-28(11)
+FUNC_START(_restgpr_26)	lwz	26,-24(11)
+FUNC_START(_restgpr_27)	lwz	27,-20(11)
+FUNC_START(_restgpr_28)	lwz	28,-16(11)
+FUNC_START(_restgpr_29)	lwz	29,-12(11)
+FUNC_START(_restgpr_30)	lwz	30,-8(11)
+FUNC_START(_restgpr_31)	lwz	31,-4(11)
+			blr
+
+/* Routines for restoring integer registers, called by the compiler.  */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area.  */
+
+FUNC_START(_restgpr_14_x)	lwz	14,-72(11)	/* restore gp registers */
+FUNC_START(_restgpr_15_x)	lwz	15,-68(11)
+FUNC_START(_restgpr_16_x)	lwz	16,-64(11)
+FUNC_START(_restgpr_17_x)	lwz	17,-60(11)
+FUNC_START(_restgpr_18_x)	lwz	18,-56(11)
+FUNC_START(_restgpr_19_x)	lwz	19,-52(11)
+FUNC_START(_restgpr_20_x)	lwz	20,-48(11)
+FUNC_START(_restgpr_21_x)	lwz	21,-44(11)
+FUNC_START(_restgpr_22_x)	lwz	22,-40(11)
+FUNC_START(_restgpr_23_x)	lwz	23,-36(11)
+FUNC_START(_restgpr_24_x)	lwz	24,-32(11)
+FUNC_START(_restgpr_25_x)	lwz	25,-28(11)
+FUNC_START(_restgpr_26_x)	lwz	26,-24(11)
+FUNC_START(_restgpr_27_x)	lwz	27,-20(11)
+FUNC_START(_restgpr_28_x)	lwz	28,-16(11)
+FUNC_START(_restgpr_29_x)	lwz	29,-12(11)
+FUNC_START(_restgpr_30_x)	lwz	30,-8(11)
+FUNC_START(_restgpr_31_x)	lwz	0,4(11)
+				lwz	31,-4(11)
+				mtlr	0
+				mr	1,11
+				blr
+#endif

-- 
1.5.4.1

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.

To workaround this issue, we just stole the save/restore code from gcc
and simplified it down for our needs (integer only).

Why can't we link with libgcc, instead?


Segher

On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.

We don't link with libgcc anywhere in the kernel.  Is this going to have
similar impacts for building the vmlinux itself?

What are they actually error messages you see with that version of GCC,
out of curiosity?

josh

On May 2, 2008, at 6:54 AM, Segher Boessenkool wrote:

quoted

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.

To workaround this issue, we just stole the save/restore code from gcc
and simplified it down for our needs (integer only).

Why can't we link with libgcc, instead?

we possibly could, the problem is knowing the path of libgcc to link with.  This seemed easier to me than the makefile headaches to ensure that we get that right.

- k

On May 2, 2008, at 7:13 AM, Josh Boyer wrote:

On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:

quoted

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.

We don't link with libgcc anywhere in the kernel.  Is this going to have
similar impacts for building the vmlinux itself?

Not by default.  The issue only shows up with -Os.  Not sure if we can build the kernel that way.

What are they actually error messages you see with that version of GCC,
out of curiosity?

  CC      fs/qnx4/qnx4.mod.o
arch/powerpc/boot/cuboot-85xx.o: In function `setprop':
/home/galak/git/linux-2.6/arch/powerpc/boot/ops.h:114: undefined reference to `_restgpr_30_x'
arch/powerpc/boot/cuboot-85xx.o: In function `platform_init':
/home/galak/git/linux-2.6/arch/powerpc/boot/cuboot-85xx.c:60: undefined reference to `_restgpr_25_x'
arch/powerpc/boot/cuboot-85xx.o: In function `find_node_by_devtype':
/home/galak/git/linux-2.6/arch/powerpc/boot/ops.h:163: undefined reference to `_restgpr_29_x'
arch/powerpc/boot/cuboot-85xx.o: In function `platform_fixups':
/home/galak/git/linux-2.6/arch/powerpc/boot/cuboot-85xx.c:51: undefined reference to `_restgpr_25_x'
  CC      fs/sysv/sysv.mod.o
arch/powerpc/boot/wrapper.a(main.o): In function `setprop':
/home/galak/git/linux-2.6/arch/powerpc/boot/ops.h:114: undefined reference to `_restgpr_30_x'
arch/powerpc/boot/wrapper.a(main.o): In function `start':
/home/galak/git/linux-2.6/arch/powerpc/boot/main.c:207: undefined reference to `_restgpr_24_x'
arch/powerpc/boot/wrapper.a(libfdt-wrapper.o): In function `fdt_init':
/home/galak/git/linux-2.6/arch/powerpc/boot/libfdt-wrapper.c:193: undefined reference to `_restgpr_30_x'

...

/home/galak/git/linux-2.6/arch/powerpc/boot/libfdt/fdt_wip.c:132: undefined reference to `_restgpr_26_x'
arch/powerpc/boot/wrapper.a(fdt_wip.o): In function `fdt_nop_node':
/home/galak/git/linux-2.6/arch/powerpc/boot/libfdt/fdt_wip.c:144: undefined reference to `_restgpr_28_x'
arch/powerpc/boot/wrapper.a(fdt_wip.o): In function `fdt_setprop_inplace':
/home/galak/git/linux-2.6/arch/powerpc/boot/libfdt/fdt_wip.c:73: undefined reference to `_restgpr_29_x'
make[1]: *** [arch/powerpc/boot/cuImage.mpc8560ads] Error 1
  CC      lib/libcrc32c.mod.o
  CC      net/key/af_key.mod.o

- k

quoted

Why can't we link with libgcc, instead?

we possibly could, the problem is knowing the path of libgcc to link with.

gcc -print-libgcc-file-name

  This seemed easier to me than the makefile headaches to ensure that we get that right.

Ah come on, make syntax is fun!


Segher

On May 2, 2008, at 8:37 AM, Segher Boessenkool wrote:

quoted

quoted

Why can't we link with libgcc, instead?

we possibly could, the problem is knowing the path of libgcc to link with.

gcc -print-libgcc-file-name

It wasn't clear if we used a multilib toolchain if we always get the proper libgcc since we are building bootwrappers for all kinda of variants.  (e500, 40x, 6xx, etc.).  My patch seemed the least painful solution to me.

I assume there is a reason we don't link libgcc w/the kernel.

quoted

 This seemed easier to me than the makefile headaches to ensure that we get that right.

Ah come on, make syntax is fun!

Yes, yes it is ;)

- k

On Fri, 2 May 2008 08:32:12 -0500
Kumar Gala [off-list ref] wrote:

On May 2, 2008, at 7:13 AM, Josh Boyer wrote:

quoted

On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:

quoted

GCC 4.4.x looks to be adding support for generating out-of-line  
register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get  
the
implementation of the register save/restores.

We don't link with libgcc anywhere in the kernel.  Is this going to  
have
similar impacts for building the vmlinux itself?

Not by default.  The issue only shows up with -Os.  Not sure if we can  
build the kernel that way.

We can.  See CONFIG_CC_OPTIMIZE_FOR_SIZE.  That's set in at least
pseries_defconfig and ps3_defconfig.  It's also something I've been
thinking about trying with 4xx.

Seems we need a bit more than just the bootwrapper.

josh

On May 2, 2008, at 8:53 AM, Josh Boyer wrote:

On Fri, 2 May 2008 08:32:12 -0500
Kumar Gala [off-list ref] wrote:

quoted

On May 2, 2008, at 7:13 AM, Josh Boyer wrote:

quoted

On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote:

quoted

GCC 4.4.x looks to be adding support for generating out-of-line
register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get
the
implementation of the register save/restores.

We don't link with libgcc anywhere in the kernel.  Is this going to
have
similar impacts for building the vmlinux itself?

Not by default.  The issue only shows up with -Os.  Not sure if we can
build the kernel that way.

We can.  See CONFIG_CC_OPTIMIZE_FOR_SIZE.  That's set in at least
pseries_defconfig and ps3_defconfig.  It's also something I've been
thinking about trying with 4xx.

Seems we need a bit more than just the bootwrapper.

building w/this enabled and will produce a patch for the kernel if needed.

- k

On May 2, 2008, at 6:54 AM, Segher Boessenkool wrote:

quoted

GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.

To workaround this issue, we just stole the save/restore code from gcc
and simplified it down for our needs (integer only).

Why can't we link with libgcc, instead?

Do you have or can you generate a ppc64 toolchain with this patch in it?

- k

On Fri, May 02, 2008 at 08:41:27AM -0500, Kumar Gala wrote:

I assume there is a reason we don't link libgcc w/the kernel.

Inertia?

BTW, it looks like ARM, SuperH, PA-Risc, and a few others do link in
libgcc.

-Scott

quoted

Why can't we link with libgcc, instead?

Do you have or can you generate a ppc64 toolchain with this patch in it?

I'm not sure what you mean.

I build GCC TOT toolchains sort-of daily, and build the kernel
with it (all architectures).  I don't build any 4xx config though,
maybe I should.


Segher

quoted

gcc -print-libgcc-file-name

It wasn't clear if we used a multilib toolchain if we always get the proper libgcc since we are building bootwrappers for all kinda of variants.  (e500, 40x, 6xx, etc.).

gcc -mthe-options-to-select-some-target -print-libgcc-file-name

My patch seemed the least painful solution to me.

In the short term, perhaps ;-)

I assume there is a reason we don't link libgcc w/the kernel.

It's historical, even _if_ there was a valid reason once (and I'm
not so sure about that), who knows if there still is.

Besides, this is not the kernel, this is the bootwrapper, I strongly
doubt libgcc would cause any conflicts here.


Segher

On May 2, 2008, at 12:11 PM, Segher Boessenkool wrote:

quoted

quoted

Why can't we link with libgcc, instead?

Do you have or can you generate a ppc64 toolchain with this patch in it?

I'm not sure what you mean.

Sorry, I meant the gcc patch.  I'm not sure if this has been committed to FSF head or not.

I build GCC TOT toolchains sort-of daily, and build the kernel
with it (all architectures).  I don't build any 4xx config though,
maybe I should.

I'm guessing you haven't seen this issue yet.

- k

From: Kumar Gala <redacted>
Date: Fri, 2 May 2008 16:28:36 -0500

Sorry, I meant the gcc patch.  I'm not sure if this has been committed  
to FSF head or not.

If that's the case it would be a good idea to suggest a command line
option to disable the new out-of-line code generation feature of that
patch.

But if the stubs it calls are really simple, you can just add
implementations under arch/powerpc/lib/, and therefore it's
not such a big deal.  This is what we've traditionally done
with libcalls generated by gcc for runtime support.

On May 2, 2008, at 4:40 PM, David Miller wrote:

From: Kumar Gala <redacted>
Date: Fri, 2 May 2008 16:28:36 -0500

quoted

Sorry, I meant the gcc patch.  I'm not sure if this has been committed
to FSF head or not.

If that's the case it would be a good idea to suggest a command line
option to disable the new out-of-line code generation feature of that
patch.

But if the stubs it calls are really simple, you can just add
implementations under arch/powerpc/lib/, and therefore it's
not such a big deal.  This is what we've traditionally done
with libcalls generated by gcc for runtime support.

They are pretty simple.

http://patchwork.ozlabs.org/linuxppc/patch?id=18292
http://patchwork.ozlabs.org/linuxppc/patch?id=18290

I've got a toolchain from CodeSourcery that has the GCC change in it and was posting this as preemptive for the point in time when FSF GCC has it.  At which point the whole discussion about why don't we just link libgcc started up :)

- k

On Fri, 2008-05-02 at 14:40 -0700, David Miller wrote:

From: Kumar Gala <redacted>
Date: Fri, 2 May 2008 16:28:36 -0500

quoted

Sorry, I meant the gcc patch.  I'm not sure if this has been committed  
to FSF head or not.

If that's the case it would be a good idea to suggest a command line
option to disable the new out-of-line code generation feature of that
patch.

But if the stubs it calls are really simple, you can just add
implementations under arch/powerpc/lib/, and therefore it's
not such a big deal.  This is what we've traditionally done
with libcalls generated by gcc for runtime support.

My only worry with this is modules.

That is, it would be fairly non-sensical for module code to go through
the trampoline to call those stubs in the kernel (and having to
EXPORT_SYMBOL them).

In the case of those register save stubs, I believe they should really
be linked with the modules.

Ben.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 03 May 2008 09:27:55 +1000

That is, it would be fairly non-sensical for module code to go through
the trampoline to call those stubs in the kernel (and having to
EXPORT_SYMBOL them).

Oh, I forgot about how far function calls are done on powerpc.
Yes, that will suck.

Is there some way to map all of the modules in the low 32-bits and
thus aovid the trampolines?  The powerpc call instruction can cover
4GB like on sparc right?

Actually, I remember there is some linkage register that has
to be setup on powerpc with the code model you guys use, is
that the problem?

quoted

That is, it would be fairly non-sensical for module code to go through
the trampoline to call those stubs in the kernel (and having to
EXPORT_SYMBOL them).

You can link every module to libgcc separately.  Probably it can also
be set up so that some libgcc routines get linked into the kernel,
and exported, and the rest is linked into every module that wants
them.  We can also blacklist some symbols altogether (__udivdi3...)

Oh, I forgot about how far function calls are done on powerpc.
Yes, that will suck.

Is there some way to map all of the modules in the low 32-bits and
thus aovid the trampolines?  The powerpc call instruction can cover
4GB like on sparc right?

A direct call reaches +-32MB, either relative or absolute; an indirect
call can go anywhere.

Actually, I remember there is some linkage register that has
to be setup on powerpc with the code model you guys use, is
that the problem?

I think the problem is just that the compiler generates "near" calls
(the 32MB thing) because of the code model used, but things don't
necessarily end up this close by at run time.


Segher

On Fri, 2008-05-02 at 16:38 -0700, David Miller wrote:

Oh, I forgot about how far function calls are done on powerpc.
Yes, that will suck.

Is there some way to map all of the modules in the low 32-bits and
thus aovid the trampolines?  The powerpc call instruction can cover
4GB like on sparc right?

Actually, I remember there is some linkage register that has
to be setup on powerpc with the code model you guys use, is
that the problem?

The TOC yes, so we end up doing cross-TOC calls, which we would want to
avoid to get to base runtime stuff such as the save/restore bits.

Especially useless since those runtime don't need a TOC at all :-)

Best would be if we could get those runtime bits linked in the module
itself, but I don't know enough about our toolchain to know if that's
easy (I suppose everything is always possible :-)

I can ask my local expert next week.

Ben.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 03 May 2008 17:50:17 +1000

Best would be if we could get those runtime bits linked in the module
itself, but I don't know enough about our toolchain to know if that's
easy (I suppose everything is always possible :-)

The only downside is that you'd have N copies of these
routines, one for every module that emmited the libcalls.

On Sat, 2008-05-03 at 00:55 -0700, David Miller wrote:

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 03 May 2008 17:50:17 +1000

quoted

Best would be if we could get those runtime bits linked in the module
itself, but I don't know enough about our toolchain to know if that's
easy (I suppose everything is always possible :-)

The only downside is that you'd have N copies of these
routines, one for every module that emmited the libcalls.

Yup, so it's mostly a matter of balance, choosing which of these should
be kept in the kernel and which of these linked directly I suppose,
possibly based on usage frequency and size. A pain in the neck tho...

Ben.

On Sat, May 03, 2008 at 12:55:10AM -0700, David Miller wrote:

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 03 May 2008 17:50:17 +1000

quoted

Best would be if we could get those runtime bits linked in the module
itself, but I don't know enough about our toolchain to know if that's
easy (I suppose everything is always possible :-)

The only downside is that you'd have N copies of these
routines, one for every module that emmited the libcalls.

It's probably not as bad as it seems: 

1) it will be smaller than having the saved/restore inlined in every 
function prologue and epilogue

2) as soon as you have ten functions or so that call them, it might
even be smaller than the size of all the trampolines. Unless I'm
mistaken, you would need at least two trampolines for every entry
point that you use in the save/restore routines, which have an entry
point at every instruction boundary or so. That's about 32 bytes
(8 instructions) per set of save/restore functions IIRC.

The ultimate solution might be lo link all these routines at a fixed
large absolute address (between -32M and -1UL) so that you can
call them with a bla instruction. But this requires memory layout
changes which would be quite painful.

	Regards,
	Gabriel