* [PATCH] Move __this_module to xxx.mod.c
@ 2003-02-16 21:23 Brian Gerst
2003-02-17 1:57 ` Kai Germaschewski
0 siblings, 1 reply; 6+ messages in thread
From: Brian Gerst @ 2003-02-16 21:23 UTC (permalink / raw)
To: kai, Linus Torvalds; +Cc: Linux-Kernel
[-- Attachment #1: Type: text/plain, Size: 182 bytes --]
This patch moves the module structure to the generated .mod.c file,
instead of compiling it into each object and relying on the linker to
include it only once.
--
Brian Gerst
[-- Attachment #2: this_module-1 --]
[-- Type: text/plain, Size: 3652 bytes --]
diff -urN linux-2.5.61-bk1/arch/v850/Makefile linux/arch/v850/Makefile
--- linux-2.5.61-bk1/arch/v850/Makefile 2003-02-10 14:22:14.000000000 -0500
+++ linux/arch/v850/Makefile 2003-02-16 14:00:47.000000000 -0500
@@ -22,11 +22,6 @@
CFLAGS += -fno-builtin
CFLAGS += -D__linux__ -DUTS_SYSNAME=\"uClinux\"
-# This prevents the linker from consolidating the .gnu.linkonce.this_module
-# section into .text (which the v850 default linker script for -r does for
-# some reason)
-LDFLAGS_MODULE += --unique=.gnu.linkonce.this_module
-
LDFLAGS_BLOB := -b binary --oformat elf32-little
OBJCOPY_FLAGS_BLOB := -I binary -O elf32-little -B v850e
diff -urN linux-2.5.61-bk1/include/linux/module.h linux/include/linux/module.h
--- linux-2.5.61-bk1/include/linux/module.h 2003-02-16 10:06:35.000000000 -0500
+++ linux/include/linux/module.h 2003-02-16 13:01:25.000000000 -0500
@@ -406,19 +406,6 @@
#ifdef MODULE
extern struct module __this_module;
-#ifdef KBUILD_MODNAME
-/* We make the linker do some of the work. */
-struct module __this_module
-__attribute__((section(".gnu.linkonce.this_module"))) = {
- .name = __stringify(KBUILD_MODNAME),
- .symbols = { .owner = &__this_module },
- .gpl_symbols = { .owner = &__this_module, .gplonly = 1 },
- .init = init_module,
-#ifdef CONFIG_MODULE_UNLOAD
- .exit = cleanup_module,
-#endif
-};
-#endif /* KBUILD_MODNAME */
#endif /* MODULE */
#define symbol_request(x) try_then_request_module(symbol_get(x), "symbol:" #x)
diff -urN linux-2.5.61-bk1/kernel/module.c linux/kernel/module.c
--- linux-2.5.61-bk1/kernel/module.c 2003-02-16 10:06:35.000000000 -0500
+++ linux/kernel/module.c 2003-02-16 14:10:29.000000000 -0500
@@ -1125,7 +1125,7 @@
strindex = sechdrs[i].sh_link;
DEBUGP("String table found in section %u\n", strindex);
} else if (strcmp(secstrings+sechdrs[i].sh_name,
- ".gnu.linkonce.this_module") == 0) {
+ "___this_module") == 0) {
/* The module struct */
DEBUGP("Module in section %u\n", i);
modindex = i;
diff -urN linux-2.5.61-bk1/scripts/modpost.c linux/scripts/modpost.c
--- linux-2.5.61-bk1/scripts/modpost.c 2003-02-16 10:06:35.000000000 -0500
+++ linux/scripts/modpost.c 2003-02-16 14:10:19.000000000 -0500
@@ -287,6 +287,10 @@
/* undefined symbol */
if (ELF_ST_BIND(sym->st_info) != STB_GLOBAL)
break;
+
+ /* ignore __this_module */
+ if (!strcmp(symname, "__this_module"))
+ break;
s = alloc_symbol(symname);
/* add to list */
@@ -378,7 +382,7 @@
/* Header for the generated file */
void
-add_header(struct buffer *b)
+add_header(struct buffer *b, struct module *mod)
{
buf_printf(b, "#include <linux/module.h>\n");
buf_printf(b, "#include <linux/vermagic.h>\n");
@@ -386,6 +390,17 @@
buf_printf(b, "const char vermagic[]\n");
buf_printf(b, "__attribute__((section(\"__vermagic\"))) =\n");
buf_printf(b, "VERMAGIC_STRING;\n");
+ buf_printf(b, "\n");
+ buf_printf(b, "struct module __this_module\n");
+ buf_printf(b, "__attribute__((section(\"___this_module\"))) = {\n");
+ buf_printf(b, "\t.name = \"%s\",\n", strrchr(mod->name, '/') + 1);
+ buf_printf(b, "\t.symbols = { .owner = &__this_module },\n");
+ buf_printf(b, "\t.gpl_symbols = { .owner = &__this_module, .gplonly = 1 },\n");
+ buf_printf(b, "\t.init = init_module,\n");
+ buf_printf(b, "#ifdef CONFIG_MODULE_UNLOAD\n");
+ buf_printf(b, "\t.exit = cleanup_module,\n");
+ buf_printf(b, "#endif\n");
+ buf_printf(b, "};\n");
}
/* Record CRCs for unresolved symbols */
@@ -526,7 +541,7 @@
buf.pos = 0;
- add_header(&buf);
+ add_header(&buf, mod);
add_versions(&buf, mod);
add_depends(&buf, mod, modules);
add_moddevtable(&buf, mod);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Move __this_module to xxx.mod.c
2003-02-16 21:23 [PATCH] Move __this_module to xxx.mod.c Brian Gerst
@ 2003-02-17 1:57 ` Kai Germaschewski
2003-02-17 2:29 ` Brian Gerst
2003-02-17 3:42 ` Rusty Russell
0 siblings, 2 replies; 6+ messages in thread
From: Kai Germaschewski @ 2003-02-17 1:57 UTC (permalink / raw)
To: Brian Gerst; +Cc: Linus Torvalds, linux-kernel, Rusty Russell
On Sun, 16 Feb 2003, Brian Gerst wrote:
> This patch moves the module structure to the generated .mod.c file,
> instead of compiling it into each object and relying on the linker to
> include it only once.
Yeah, it's something I though about doing, but I was not sure. I think
it's up to Rusty to comment ;)
It will need an associated change to module_init_tools.
Another comment:
diff -urN linux-2.5.61-bk1/scripts/modpost.c linux/scripts/modpost.c
--- linux-2.5.61-bk1/scripts/modpost.c 2003-02-16 10:06:35.000000000 -0500
+++ linux/scripts/modpost.c 2003-02-16 14:10:19.000000000 -0500
@@ -287,6 +287,10 @@
/* undefined symbol */
if (ELF_ST_BIND(sym->st_info) != STB_GLOBAL)
break;
+
+ /* ignore __this_module */
+ if (!strcmp(symname, "__this_module"))
+ break;
s = alloc_symbol(symname);
/* add to list */
Is that necessary? __this_module shouldn't be unresolved, so this case
should never be hit AFAICS.
--Kai
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Move __this_module to xxx.mod.c
2003-02-17 1:57 ` Kai Germaschewski
@ 2003-02-17 2:29 ` Brian Gerst
2003-02-17 3:42 ` Rusty Russell
1 sibling, 0 replies; 6+ messages in thread
From: Brian Gerst @ 2003-02-17 2:29 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Linus Torvalds, linux-kernel, Rusty Russell
Kai Germaschewski wrote:
> On Sun, 16 Feb 2003, Brian Gerst wrote:
>
>
> >This patch moves the module structure to the generated .mod.c file,
> >instead of compiling it into each object and relying on the linker to
> >include it only once.
>
>
> Yeah, it's something I though about doing, but I was not sure. I think
> it's up to Rusty to comment ;)
>
> It will need an associated change to module_init_tools.
>
> Another comment:
>
> diff -urN linux-2.5.61-bk1/scripts/modpost.c linux/scripts/modpost.c
> --- linux-2.5.61-bk1/scripts/modpost.c 2003-02-16 10:06:35.000000000 -0500
> +++ linux/scripts/modpost.c 2003-02-16 14:10:19.000000000 -0500
> @@ -287,6 +287,10 @@
> /* undefined symbol */
> if (ELF_ST_BIND(sym->st_info) != STB_GLOBAL)
> break;
> +
> + /* ignore __this_module */
> + if (!strcmp(symname, "__this_module"))
> + break;
>
> s = alloc_symbol(symname);
> /* add to list */
>
> Is that necessary? __this_module shouldn't be unresolved, so this case
> should never be hit AFAICS.
After the definition is removed from module.h, it is unresolved before
it is linked to xxx.mod.c.
--
Brian Gerst
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Move __this_module to xxx.mod.c
2003-02-17 1:57 ` Kai Germaschewski
2003-02-17 2:29 ` Brian Gerst
@ 2003-02-17 3:42 ` Rusty Russell
2003-02-17 4:26 ` Kai Germaschewski
1 sibling, 1 reply; 6+ messages in thread
From: Rusty Russell @ 2003-02-17 3:42 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Brian Gerst, Linus Torvalds, linux-kernel
In message <Pine.LNX.4.44.0302161946220.5217-100000@chaos.physics.uiowa.edu> yo
u write:
> On Sun, 16 Feb 2003, Brian Gerst wrote:
>
> > This patch moves the module structure to the generated .mod.c file,
> > instead of compiling it into each object and relying on the linker to
> > include it only once.
>
> Yeah, it's something I though about doing, but I was not sure. I think
> it's up to Rusty to comment ;)
>
> It will need an associated change to module_init_tools.
I don't think so: the symbol will be in the module by the time
module-init-tools gets to it, or am I missing something?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Move __this_module to xxx.mod.c
2003-02-17 3:42 ` Rusty Russell
@ 2003-02-17 4:26 ` Kai Germaschewski
2003-02-17 4:53 ` Rusty Russell
0 siblings, 1 reply; 6+ messages in thread
From: Kai Germaschewski @ 2003-02-17 4:26 UTC (permalink / raw)
To: Rusty Russell; +Cc: Brian Gerst, Linus Torvalds, linux-kernel
On Mon, 17 Feb 2003, Rusty Russell wrote:
> I don't think so: the symbol will be in the module by the time
> module-init-tools gets to it, or am I missing something?
Yes, but modprobe will look for .gnu.linkonce.__this_module if it wants to
change the name (but that's now in ___this_module).
--Kai
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Move __this_module to xxx.mod.c
2003-02-17 4:26 ` Kai Germaschewski
@ 2003-02-17 4:53 ` Rusty Russell
0 siblings, 0 replies; 6+ messages in thread
From: Rusty Russell @ 2003-02-17 4:53 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Brian Gerst, Linus Torvalds, linux-kernel
In message <Pine.LNX.4.44.0302162225420.5217-100000@chaos.physics.uiowa.edu> yo
u write:
> On Mon, 17 Feb 2003, Rusty Russell wrote:
>
> > I don't think so: the symbol will be in the module by the time
> > module-init-tools gets to it, or am I missing something?
>
> Yes, but modprobe will look for .gnu.linkonce.__this_module if it wants to
> change the name (but that's now in ___this_module).
Good point. The name change thing is a known hack, of course, but
will fix userspace.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-02-17 5:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-16 21:23 [PATCH] Move __this_module to xxx.mod.c Brian Gerst
2003-02-17 1:57 ` Kai Germaschewski
2003-02-17 2:29 ` Brian Gerst
2003-02-17 3:42 ` Rusty Russell
2003-02-17 4:26 ` Kai Germaschewski
2003-02-17 4:53 ` Rusty Russell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox