Re: 2.6.26-rc5-mm1: uml link error

[Peter Oberparleiter]

Sam Ravnborg wrote:
> On Tue, Jun 10, 2008 at 04:21:06PM +0200, Peter Oberparleiter wrote:
>> Peter 1 Oberparleiter wrote:
>> > Jeff Dike <jdike@xxxxxxxxxxx> wrote on 10.06.2008 15:57:29:
>> > 
>> >> On Tue, Jun 10, 2008 at 01:19:27PM +0200, Miklos Szeredi wrote:
>> >> > Hmm, uml still doesn't boot with this patch, it dies while calling the
>> >> > constructors.  So maybe that SORT contruct is still needed?
>> >> > 
>> >> > #17 0x08049793 in do_ctors () at init/main.c:706
>> >> > #18 0x080499cc in do_basic_setup () at init/main.c:789
>> >> > #19 0x08049a43 in kernel_init (unused=0x0) at init/main.c:897
>> >> 
>> >> This doesn't look like it's in do_initcalls.  What happens with
>> >> "initcall_debug"?
>> > 
>> > Constructor calls inside the kernel happen just before any other
>> > initcall. The problem here is that constructors are called from both
>> > the host run-time environment as well as from the kernel. I'm
>> > working on a patch that disables kernel constructor calling for UML.
>> 
>> New try: should be fixed with the patch below (applies on top of
>> kernel-call-constructors.patch):
>> 
>> --
>> Subject: kernel: disable constructor calling for uml
>> 
>> From: Peter Oberparleiter <peter.oberparleiter@xxxxxxxxxx>
>> 
>> Disable calling of constructor functions from within the kernel for uml
>> as they are already called by the host run-time environment.
> 
> If this is the right fix then could we please have a less ugly patch.
> First off there is no need for the ifdef in vmlinux.lds.h.

Agreed. In that case the SORT(CONSTRUCTORS) statement in
arch/um/kernel/dyn.lds.S needs to be changed as well though (see my
previous patch in this thread) or we get the linker error detailed
in the original post.

> And we could get away with some flag or something where we 
> call the constructors.

The decision whether constructors should be called or not is made at
configuratiom time - I don't see a variable fitting into this scheme.
The only alternative I could imagine would be to introduce a hidden
config symbol CONFIG_CTORS which would be auto-selected by all archs
except for uml.

> And a comment explaning why UML is different is also missing.

Done. Here comes the modifed patch: applies on top of
kernel-call-constructors.patch, together with the remove-sort-
construct patch:

--
kernel: disable constructor calling for uml

From: Peter Oberparleiter <peter.oberparleiter@xxxxxxxxxx>

Disable calling of constructor functions for uml as they are already
called by the host run-time environment.

Found-by: Miklos Szeredi <miklos@xxxxxxxxxx>
Signed-off-by: Peter Oberparleiter <peter.oberparleiter@xxxxxxxxxx>
---
 init/main.c     |    4 ++++
 kernel/module.c |    4 ++++
 2 files changed, 8 insertions(+)

Index: linux-2.6.26-rc5-mm2/init/main.c
===================================================================
--- linux-2.6.26-rc5-mm2.orig/init/main.c
+++ linux-2.6.26-rc5-mm2/init/main.c
@@ -699,11 +699,15 @@ asmlinkage void __init start_kernel(void
 
 static void __init do_ctors(void)
 {
+#ifndef CONFIG_UML
+	/* Note: constructors on UML are called by the host run-time
+	 * environment. */
 	ctorcall_t *call;
 
 	for (call = (ctorcall_t *) __ctor_start;
 	     call < (ctorcall_t *) __ctor_end; call++)
 		(*call)();
+#endif /* !CONFIG_UML */
 }
 
 static int __initdata initcall_debug;
Index: linux-2.6.26-rc5-mm2/kernel/module.c
===================================================================
--- linux-2.6.26-rc5-mm2.orig/kernel/module.c
+++ linux-2.6.26-rc5-mm2/kernel/module.c
@@ -2194,10 +2194,14 @@ static struct module *load_module(void _
 
 static void do_mod_ctors(struct module *mod)
 {
+#ifndef CONFIG_UML
+	/* Note: constructors on UML are called by the host run-time
+	 * environment. */
 	unsigned long i;
 
 	for (i = 0; i < mod->num_ctors; i++)
 		mod->ctors[i]();
+#endif /* !CONFIG_UML */
 }
 
 /* This is where the real work happens */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/