* How to link a .o with all modules @ 2008-05-04 18:22 Kumar Gala 2008-05-04 19:24 ` Sam Ravnborg 2008-05-04 23:27 ` H. Peter Anvin 0 siblings, 2 replies; 11+ messages in thread From: Kumar Gala @ 2008-05-04 18:22 UTC (permalink / raw) To: sam; +Cc: linuxppc-dev@ozlabs.org list, lkml List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-04 18:22 How to link a .o with all modules Kumar Gala @ 2008-05-04 19:24 ` Sam Ravnborg 2008-05-05 14:46 ` Kumar Gala 2008-05-04 23:27 ` H. Peter Anvin 1 sibling, 1 reply; 11+ messages in thread From: Sam Ravnborg @ 2008-05-04 19:24 UTC (permalink / raw) To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, lkml List On Sun, May 04, 2008 at 01:22:38PM -0500, Kumar Gala wrote: > 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? 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-04 19:24 ` Sam Ravnborg @ 2008-05-05 14:46 ` Kumar Gala 2008-05-05 20:44 ` Sam Ravnborg 0 siblings, 1 reply; 11+ messages in thread From: Kumar Gala @ 2008-05-05 14:46 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List On May 4, 2008, at 2:24 PM, Sam Ravnborg wrote: > On Sun, May 04, 2008 at 01:22:38PM -0500, Kumar Gala wrote: >> 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? > > 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. 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-05 14:46 ` Kumar Gala @ 2008-05-05 20:44 ` Sam Ravnborg 2008-05-08 14:16 ` Kumar Gala 0 siblings, 1 reply; 11+ messages in thread From: Sam Ravnborg @ 2008-05-05 20:44 UTC (permalink / raw) To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, lkml List > > > > > >Let me know if this does address your question. > > 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! 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-05 20:44 ` Sam Ravnborg @ 2008-05-08 14:16 ` Kumar Gala 2008-05-08 20:22 ` Sam Ravnborg 0 siblings, 1 reply; 11+ messages in thread From: Kumar Gala @ 2008-05-08 14:16 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote: >>> >>> >>> Let me know if this does address your question. >> >> 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! > > 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? No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I also be doing EXPORT_SYMBOL? > If in the linked in .o file - could you > see the symbols using objdump. 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 ... > > > etc. > > Sorry - not much help right away. > > PS. Travelling - do not expect responses until the > weekend. np. > > > Sam ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-08 14:16 ` Kumar Gala @ 2008-05-08 20:22 ` Sam Ravnborg 2008-05-09 13:52 ` Kumar Gala 2008-06-03 4:55 ` Kumar Gala 0 siblings, 2 replies; 11+ messages in thread From: Sam Ravnborg @ 2008-05-08 20:22 UTC (permalink / raw) To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, lkml List On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote: > > On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote: > > >>> > >>> > >>>Let me know if this does address your question. > >> > >>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! > > > >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? > > No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I > also be doing EXPORT_SYMBOL? So modpost claim it cannot find the symbols. > > >If in the linked in .o file - could you > >see the symbols using objdump. > > 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 > ... 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-08 20:22 ` Sam Ravnborg @ 2008-05-09 13:52 ` Kumar Gala 2008-05-12 15:51 ` Kumar Gala 2008-06-03 4:55 ` Kumar Gala 1 sibling, 1 reply; 11+ messages in thread From: Kumar Gala @ 2008-05-09 13:52 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List [-- Attachment #1: Type: text/plain, Size: 1638 bytes --] On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote: > On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote: >> >> On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote: >> >>>>> >>>>> >>>>> Let me know if this does address your question. >>>> >>>> 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! >>> >>> 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? >> >> No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I >> also be doing EXPORT_SYMBOL? > > So modpost claim it cannot find the symbols. > >> >>> If in the linked in .o file - could you >>> see the symbols using objdump. >> >> 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 >> ... > > 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 I'm assuming you mean objdump -r arch/powerpc/lib/built-in.o [-- Attachment #2: reloc.dump.gz --] [-- Type: application/x-gzip, Size: 14925 bytes --] [-- Attachment #3: Type: text/plain, Size: 1 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-09 13:52 ` Kumar Gala @ 2008-05-12 15:51 ` Kumar Gala 0 siblings, 0 replies; 11+ messages in thread From: Kumar Gala @ 2008-05-12 15:51 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List On Fri, 9 May 2008, Kumar Gala wrote: > > On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote: > > > On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote: > > > > > > On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote: > > > > > > > > > > > > > > > > > > > > > Let me know if this does address your question. > > > > > > > > > > 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! > > > > > > > > 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? > > > > > > No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I > > > also be doing EXPORT_SYMBOL? > > > > So modpost claim it cannot find the symbols. > > > > > > > > > If in the linked in .o file - could you > > > > see the symbols using objdump. > > > > > > 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 > > > ... > > > > 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 > > I'm assuming you mean objdump -r arch/powerpc/lib/built-in.o > 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 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) +FUNC_START(_save32gpr_14) + stw 14,-72(11) /* save gp registers */ +FUNC_START(_savegpr_15) +FUNC_START(_save32gpr_15) + stw 15,-68(11) +FUNC_START(_savegpr_16) +FUNC_START(_save32gpr_16) + stw 16,-64(11) +FUNC_START(_savegpr_17) +FUNC_START(_save32gpr_17) + stw 17,-60(11) +FUNC_START(_savegpr_18) +FUNC_START(_save32gpr_18) + stw 18,-56(11) +FUNC_START(_savegpr_19) +FUNC_START(_save32gpr_19) + stw 19,-52(11) +FUNC_START(_savegpr_20) +FUNC_START(_save32gpr_20) + stw 20,-48(11) +FUNC_START(_savegpr_21) +FUNC_START(_save32gpr_21) + stw 21,-44(11) +FUNC_START(_savegpr_22) +FUNC_START(_save32gpr_22) + stw 22,-40(11) +FUNC_START(_savegpr_23) +FUNC_START(_save32gpr_23) + stw 23,-36(11) +FUNC_START(_savegpr_24) +FUNC_START(_save32gpr_24) + stw 24,-32(11) +FUNC_START(_savegpr_25) +FUNC_START(_save32gpr_25) + stw 25,-28(11) +FUNC_START(_savegpr_26) +FUNC_START(_save32gpr_26) + stw 26,-24(11) +FUNC_START(_savegpr_27) +FUNC_START(_save32gpr_27) + stw 27,-20(11) +FUNC_START(_savegpr_28) +FUNC_START(_save32gpr_28) + stw 28,-16(11) +FUNC_START(_savegpr_29) +FUNC_START(_save32gpr_29) + stw 29,-12(11) +FUNC_START(_savegpr_30) +FUNC_START(_save32gpr_30) + stw 30,-8(11) +FUNC_START(_savegpr_31) +FUNC_START(_save32gpr_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) +FUNC_START(_rest32gpr_14) + lwz 14,-72(11) /* restore gp registers */ +FUNC_START(_restgpr_15) +FUNC_START(_rest32gpr_15) + lwz 15,-68(11) +FUNC_START(_restgpr_16) +FUNC_START(_rest32gpr_16) + lwz 16,-64(11) +FUNC_START(_restgpr_17) +FUNC_START(_rest32gpr_17) + lwz 17,-60(11) +FUNC_START(_restgpr_18) +FUNC_START(_rest32gpr_18) + lwz 18,-56(11) +FUNC_START(_restgpr_19) +FUNC_START(_rest32gpr_19) + lwz 19,-52(11) +FUNC_START(_restgpr_20) +FUNC_START(_rest32gpr_20) + lwz 20,-48(11) +FUNC_START(_restgpr_21) +FUNC_START(_rest32gpr_21) + lwz 21,-44(11) +FUNC_START(_restgpr_22) +FUNC_START(_rest32gpr_22) + lwz 22,-40(11) +FUNC_START(_restgpr_23) +FUNC_START(_rest32gpr_23) + lwz 23,-36(11) +FUNC_START(_restgpr_24) +FUNC_START(_rest32gpr_24) + lwz 24,-32(11) +FUNC_START(_restgpr_25) +FUNC_START(_rest32gpr_25) + lwz 25,-28(11) +FUNC_START(_restgpr_26) +FUNC_START(_rest32gpr_26) + lwz 26,-24(11) +FUNC_START(_restgpr_27) +FUNC_START(_rest32gpr_27) + lwz 27,-20(11) +FUNC_START(_restgpr_28) +FUNC_START(_rest32gpr_28) + lwz 28,-16(11) +FUNC_START(_restgpr_29) +FUNC_START(_rest32gpr_29) + lwz 29,-12(11) +FUNC_START(_restgpr_30) +FUNC_START(_rest32gpr_30) + lwz 30,-8(11) +FUNC_START(_restgpr_31) +FUNC_START(_rest32gpr_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) +FUNC_START(_rest32gpr_14_x) + lwz 14,-72(11) /* restore gp registers */ +FUNC_START(_restgpr_15_x) +FUNC_START(_rest32gpr_15_x) + lwz 15,-68(11) +FUNC_START(_restgpr_16_x) +FUNC_START(_rest32gpr_16_x) + lwz 16,-64(11) +FUNC_START(_restgpr_17_x) +FUNC_START(_rest32gpr_17_x) + lwz 17,-60(11) +FUNC_START(_restgpr_18_x) +FUNC_START(_rest32gpr_18_x) + lwz 18,-56(11) +FUNC_START(_restgpr_19_x) +FUNC_START(_rest32gpr_19_x) + lwz 19,-52(11) +FUNC_START(_restgpr_20_x) +FUNC_START(_rest32gpr_20_x) + lwz 20,-48(11) +FUNC_START(_restgpr_21_x) +FUNC_START(_rest32gpr_21_x) + lwz 21,-44(11) +FUNC_START(_restgpr_22_x) +FUNC_START(_rest32gpr_22_x) + lwz 22,-40(11) +FUNC_START(_restgpr_23_x) +FUNC_START(_rest32gpr_23_x) + lwz 23,-36(11) +FUNC_START(_restgpr_24_x) +FUNC_START(_rest32gpr_24_x) + lwz 24,-32(11) +FUNC_START(_restgpr_25_x) +FUNC_START(_rest32gpr_25_x) + lwz 25,-28(11) +FUNC_START(_restgpr_26_x) +FUNC_START(_rest32gpr_26_x) + lwz 26,-24(11) +FUNC_START(_restgpr_27_x) +FUNC_START(_rest32gpr_27_x) + lwz 27,-20(11) +FUNC_START(_restgpr_28_x) +FUNC_START(_rest32gpr_28_x) + lwz 28,-16(11) +FUNC_START(_restgpr_29_x) +FUNC_START(_rest32gpr_29_x) + lwz 29,-12(11) +FUNC_START(_restgpr_30_x) +FUNC_START(_rest32gpr_30_x) + lwz 30,-8(11) +FUNC_START(_restgpr_31_x) +FUNC_START(_rest32gpr_31_x) + lwz 0,4(11) + lwz 31,-4(11) + mtlr 0 + mr 1,11 + blr +#endif -- 1.5.4.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-08 20:22 ` Sam Ravnborg 2008-05-09 13:52 ` Kumar Gala @ 2008-06-03 4:55 ` Kumar Gala 1 sibling, 0 replies; 11+ messages in thread From: Kumar Gala @ 2008-06-03 4:55 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linuxppc-dev@ozlabs.org list, lkml List On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote: > On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote: >> >> On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote: >> >>>>> >>>>> >>>>> Let me know if this does address your question. >>>> >>>> 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! >>> >>> 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? >> >> No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I >> also be doing EXPORT_SYMBOL? > > So modpost claim it cannot find the symbols. > >> >>> If in the linked in .o file - could you >>> see the symbols using objdump. >> >> 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 >> ... > > 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, Didn't see any feedback from the relocation records. - k ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-04 18:22 How to link a .o with all modules Kumar Gala 2008-05-04 19:24 ` Sam Ravnborg @ 2008-05-04 23:27 ` H. Peter Anvin 2008-05-04 23:38 ` Paul Mackerras 1 sibling, 1 reply; 11+ messages in thread From: H. Peter Anvin @ 2008-05-04 23:27 UTC (permalink / raw) To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, sam, lkml List Kumar Gala wrote: > 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). > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: How to link a .o with all modules 2008-05-04 23:27 ` H. Peter Anvin @ 2008-05-04 23:38 ` Paul Mackerras 0 siblings, 0 replies; 11+ messages in thread From: Paul Mackerras @ 2008-05-04 23:38 UTC (permalink / raw) To: H. Peter Anvin; +Cc: linuxppc-dev@ozlabs.org list, sam, lkml List H. Peter Anvin writes: > 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...? It means we would go through a trampoline just to call little things like __ucmpdi2, which seems a bit unnecessary. Paul. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-06-03 4:55 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-04 18:22 How to link a .o with all modules Kumar Gala 2008-05-04 19:24 ` Sam Ravnborg 2008-05-05 14:46 ` Kumar Gala 2008-05-05 20:44 ` Sam Ravnborg 2008-05-08 14:16 ` Kumar Gala 2008-05-08 20:22 ` Sam Ravnborg 2008-05-09 13:52 ` Kumar Gala 2008-05-12 15:51 ` Kumar Gala 2008-06-03 4:55 ` Kumar Gala 2008-05-04 23:27 ` H. Peter Anvin 2008-05-04 23:38 ` Paul Mackerras
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).