Sam,

We have a case in powerpc in which we want to link some library  
routines with all module objects.  The routines are intended for  
handling out-of-line function call register save/restore so having  
them as EXPORT_SYMBOL() is counter productive (we do also need to link  
the same "library" code into the kernel).

Any suggestions on how to handle this?

thanks

- k
--

[ message continues ]

I assume you have the .o file build somewhere as part of the
normal kernel build.

Then you in
arch/powerpc/Makefile adds the following assignment:

LDFLAGS_MODULE += arch/powerpc/lib/my_magic_file.o

kbuild will then during the modpost stage link this
file on all modules.
To add the same file to the kernel just include it
in a obj-y += my_magic_file.o

One trap is that my_magic_file.o needs to be built
for a modules build too.
I think you need to assign it to always:

   always := my_magic_file.o

to accomplish this.

So in the end we will have:

arch/powerpc/Makefile:
LDFLAGS_MODULE += arch/powerpc/lib/my_magic_file.o

arch/powerpc/lib/Makefile:
always := my_magic_file.o
obj-y += my_magic_file.o


Let me know if this does address your question.

	Sam
--

[ message continues ]

The problem is MODPOST complains about undefined symbols:

   MODPOST 24 modules
ERROR: "_restgpr_20_x" [net/key/af_key.ko] undefined!
ERROR: "_restgpr_25_x" [net/key/af_key.ko] undefined!
ERROR: "_restgpr_30_x" [net/key/af_key.ko] undefined!

...

Any ideas on that?

- k
--

[ message continues ]

I need a bit more context to try to analyse this.
Where did you expect _restgpr_20_x to be defined.
If in vmlinux then were they present in the
Module.symvers file?

If in the linked in .o file - could you
see the symbols using objdump.

etc.

Sorry - not much help right away.

PS. Travelling - do not expect responses until the
weekend.

	Sam
--

[ message continues ]

No they aren't there since we I'm not EXPORT_SYMBOL() them.  Should I  

Yes.

readelf -a:

...
Symbol table '.symtab' contains 113 entries:
    Num:    Value  Size Type    Bind   Vis      Ndx Name
...
      5: 00000000     0 FUNC    GLOBAL DEFAULT    1 _savegpr_14
      6: 00000000     0 FUNC    GLOBAL DEFAULT    1 _save32gpr_14


--

[ message continues ]

Strange.

I did not look closer.
But it looks like the linker failed to resolve these symbols
in the final link somehow - despite the symbols are present in
the linked in .o file.

Can you try to drop me the output of the relocation records for the
finally linked .o file (the one with your .o file linked in).

objdump -r IIRC

	Sam
--

[ message continues ]

I'm assuming you mean objdump -r arch/powerpc/lib/built-in.o

[ message continues ]

Any update on this?

Here's my current patch that causes me issue:

- k

---

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..6bac266
--- /dev/null
+++ b/arch/powerpc/boot/crtsavres.S
@@ -0,0 +1,233 @@
+/*
+ * 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 ...
[ message continues ]

Sam,

Didn't see any feedback from the relocation records.

- k
--

[ message continues ]

Why is having them as an EXPORT_SYMBOL() counterproductive?  It sounds 
like *exactly* what you need -- and then having the kernel provide the 
same code to modules, instead of replication...?

	-hpa
--

[ message continues ]

It means we would go through a trampoline just to call little things
like __ucmpdi2, which seems a bit unnecessary.

Paul.
--

[ message continues ]