I get this error on linking uml:
/usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld:arch/um/kernel/vmlinux.lds:267: syntax error
Reverting 'kernel-call-constructors.patch' fixes it.
> diff -u arch/um/kernel/vmlinux.lds.bad arch/um/kernel/vmlinux.lds
--- arch/um/kernel/vmlinux.lds.bad 2008-06-09 22:35:57.000000000 +0200
+++ arch/um/kernel/vmlinux.lds 2008-06-09 22:36:07.000000000 +0200
@@ -264,7 +264,7 @@
*(.data.init_irqstack)
*(.data) *(.data.init.refok) *(.ref.data) *(.devinit.data) *(.devexit.data) . = ALIGN(8); __start___markers = .; *(__markers) __stop___markers = .;
*(.data.* .gnu.linkonce.d.*)
- SORT(__ctor_start = .; *(.ctors) __ctor_end = .;)
+ SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
Unintended macro substitution?
Thanks,
Miklos
Miklos Szeredi wrote:
> I get this error on linking uml:
>
> /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld:arch/um/kernel/vmlinux.lds:267: syntax error
>
> Reverting 'kernel-call-constructors.patch' fixes it.
Should be fixed with the patch below (applies on top of
kernel-call-constructors.patch):
--
From: Peter Oberparleiter <[email protected]>
Fix for linker error on UML:
/usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld:arch/um/kernel/vmlinux.lds:267: syntax error
The error is triggered by the use of SORT(CONSTRUCTORS) in the UML
linker script which conflicts with the kernel-call-constructors patch.
Here is what the ld info page says about sorting constructors:
If you are using the GNU C++ support for initialization priority,
which provides some control over the order in which global
constructors are run, you must sort the constructors at link time
to ensure that they are executed in the correct order.
As there's no C++ code inside the kernel it should be safe to remove
the SORT construct.
Found-by: Miklos Szeredi <[email protected]>
Signed-off-by: Peter Oberparleiter <[email protected]>
---
arch/um/kernel/dyn.lds.S | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.26-rc5-mm2/arch/um/kernel/dyn.lds.S
===================================================================
--- linux-2.6.26-rc5-mm2.orig/arch/um/kernel/dyn.lds.S
+++ linux-2.6.26-rc5-mm2/arch/um/kernel/dyn.lds.S
@@ -102,7 +102,7 @@ SECTIONS
*(.data.init_irqstack)
DATA_DATA
*(.data.* .gnu.linkonce.d.*)
- SORT(CONSTRUCTORS)
+ CONSTRUCTORS
}
.data1 : { *(.data1) }
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
> From: Peter Oberparleiter <[email protected]>
>
> Fix for linker error on UML:
>
> /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld:arch/um/kernel/vmlinux.lds:267: syntax error
>
> The error is triggered by the use of SORT(CONSTRUCTORS) in the UML
> linker script which conflicts with the kernel-call-constructors patch.
> Here is what the ld info page says about sorting constructors:
>
> If you are using the GNU C++ support for initialization priority,
> which provides some control over the order in which global
> constructors are run, you must sort the constructors at link time
> to ensure that they are executed in the correct order.
>
> As there's no C++ code inside the kernel it should be safe to remove
> the SORT construct.
Hmm, uml still doesn't boot with this patch, it dies while calling the
constructors. So maybe that SORT contruct is still needed?
Miklos
mszeredi@tucsk:/store/uml> /store/quilt/linux/linux umid=uml
Locating the bottom of the address space ... 0x0
Locating the top of the address space ... 0xffffd000
Core dump limits :
soft - NONE
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...missing
Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm
Checking PROT_EXEC mmap in /tmp/...OK
Checking for the skas3 patch in the host:
- /proc/mm...not found: No such file or directory
- PTRACE_FAULTINFO...not found
- PTRACE_LDT...not found
UML running in SKAS0 mode
Adding 15208448 bytes to physical memory to account for exec-shield gap
Aborted (core dumped)
mszeredi@tucsk:/store/uml> gdb /store/quilt/linux/linux core
GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `/store/quilt/linux/linux umid=uml'.
Program terminated with signal 6, Aborted.
#0 0xffffe430 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xf7e598f5 in raise () from /lib/libc.so.6
#2 0xf7e5b1e1 in abort () from /lib/libc.so.6
#3 0x0807173d in os_dump_core () at arch/um/os-Linux/util.c:119
#4 0x08061d07 in panic_exit (self=0x8451594, unused1=0, unused2=0x8471f20) at arch/um/kernel/um_arch.c:233
#5 0x0809a2ea in notifier_call_chain (nl=0x84594ec, val=0, v=0x8471f20, nr_to_call=-1, nr_calls=0x0)
at kernel/notifier.c:85
#6 0x0809a3e0 in __atomic_notifier_call_chain (nh=0x84594dc, val=0, v=0x8471f20, nr_to_call=-1, nr_calls=0x0)
at kernel/notifier.c:174
#7 0x0809a41f in atomic_notifier_call_chain (nh=0x84594dc, val=0, v=0x8471f20) at kernel/notifier.c:183
#8 0x0807e88a in panic (fmt=0x83dd7be "Segfault with no mm") at kernel/panic.c:104
#9 0x08061922 in segv (fi={error_code = 21, cr2 = 4294967295, trap_no = 14}, ip=4294967295, is_user=0,
regs=0x844fc70) at arch/um/kernel/trap.c:176
#10 0x080616c7 in segv_handler (sig=11, regs=0x6) at arch/um/kernel/trap.c:152
#11 0x0806ff00 in sig_handler_common (sig=11, sc=0x844fd24) at arch/um/os-Linux/signal.c:49
#12 0x0806ff87 in sig_handler (sig=11, sc=0x844fd24) at arch/um/os-Linux/signal.c:81
#13 0x0807011d in handle_signal (sig=2894, sc=0x844fd24) at arch/um/os-Linux/signal.c:158
#14 0x08071fb8 in hard_handler (sig=11) at arch/um/os-Linux/sys-i386/signal.c:12
#15 <signal handler called>
#16 0xffffffff in ?? ()
#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
#20 0x0806f241 in run_kernel_thread (fn=0x8049a10 <kernel_init>, arg=0x0, jmp_ptr=0xa860b50)
at arch/um/os-Linux/process.c:267
#21 0x0805ed02 in new_thread_handler () at arch/um/kernel/process.c:151
#22 0x00000000 in ?? ()
(gdb)
Miklos
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"?
Jeff
--
Work email - jdike at linux dot intel dot com
> > 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"?
Same output:
mszeredi@tucsk:/store/uml> /store/quilt/linux/linux initcall_debug umid=uml
Locating the bottom of the address space ... 0x0
Locating the top of the address space ... 0xffffd000
Core dump limits :
soft - NONE
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...missing
Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm
Checking PROT_EXEC mmap in /tmp/...OK
Checking for the skas3 patch in the host:
- /proc/mm...not found: No such file or directory
- PTRACE_FAULTINFO...not found
- PTRACE_LDT...not found
UML running in SKAS0 mode
Adding 19943424 bytes to physical memory to account for exec-shield gap
Aborted (core dumped)
Jeff Dike <[email protected]> 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.
Regards,
Peter
Peter 1 Oberparleiter wrote:
> Jeff Dike <[email protected]> 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 <[email protected]>
Disable calling of constructor functions from within the kernel for uml
as they are already called by the host run-time environment.
Found-by: Miklos Szeredi <[email protected]>
Signed-off-by: Peter Oberparleiter <[email protected]>
---
include/asm-generic/vmlinux.lds.h | 2 ++
init/main.c | 2 ++
kernel/module.c | 2 ++
3 files changed, 6 insertions(+)
Index: linux-2.6.26-rc5-mm2/include/asm-generic/vmlinux.lds.h
===================================================================
--- linux-2.6.26-rc5-mm2.orig/include/asm-generic/vmlinux.lds.h
+++ linux-2.6.26-rc5-mm2/include/asm-generic/vmlinux.lds.h
@@ -381,7 +381,9 @@
} \
__per_cpu_end = .;
+#ifndef CONFIG_UML
#define CONSTRUCTORS \
VMLINUX_SYMBOL(__ctor_start) = .; \
*(.ctors) \
VMLINUX_SYMBOL(__ctor_end) = .;
+#endif /* !CONFIG_UML */
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,13 @@ asmlinkage void __init start_kernel(void
static void __init do_ctors(void)
{
+#ifndef CONFIG_UML
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,12 @@ static struct module *load_module(void _
static void do_mod_ctors(struct module *mod)
{
+#ifndef CONFIG_UML
unsigned long i;
for (i = 0; i < mod->num_ctors; i++)
mod->ctors[i]();
+#endif /* !CONFIG_UML */
}
/* This is where the real work happens */
On Tue, Jun 10, 2008 at 04:21:06PM +0200, Peter Oberparleiter wrote:
> Subject: kernel: disable constructor calling for uml
>
> From: Peter Oberparleiter <[email protected]>
>
> Disable calling of constructor functions from within the kernel for uml
> as they are already called by the host run-time environment.
I can't believe this is the right fix.
I was confusing this with initcalls before. Let me take a look and
see what's really going on...
Jeff
--
Work email - jdike at linux dot intel dot com
On Tue, Jun 10, 2008 at 04:21:06PM +0200, Peter Oberparleiter wrote:
> Subject: kernel: disable constructor calling for uml
>
> From: Peter Oberparleiter <[email protected]>
>
> Disable calling of constructor functions from within the kernel for uml
> as they are already called by the host run-time environment.
OK, maybe it is the right fix. I didn't realize it was for gcov
support only.
It's still kinda ugly though. If you stick with this, I'd put
comments on those ifdefs saying why UML is special.
Jeff
--
Work email - jdike at linux dot intel dot com
On Tue, Jun 10, 2008 at 04:21:06PM +0200, Peter Oberparleiter wrote:
> Peter 1 Oberparleiter wrote:
> > Jeff Dike <[email protected]> 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 <[email protected]>
>
> 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.
And we could get away with some flag or something where we
call the constructors.
And a comment explaning why UML is different is also missing.
Sam
Sam Ravnborg wrote:
> On Tue, Jun 10, 2008 at 04:21:06PM +0200, Peter Oberparleiter wrote:
>> Peter 1 Oberparleiter wrote:
>> > Jeff Dike <[email protected]> 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 <[email protected]>
>>
>> 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 <[email protected]>
Disable calling of constructor functions for uml as they are already
called by the host run-time environment.
Found-by: Miklos Szeredi <[email protected]>
Signed-off-by: Peter Oberparleiter <[email protected]>
---
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 */
> 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:
With both patches applied builds and boots fine. Thanks.
> --
> kernel: disable constructor calling for uml
>
> From: Peter Oberparleiter <[email protected]>
>
> Disable calling of constructor functions for uml as they are already
> called by the host run-time environment.
>
> Found-by: Miklos Szeredi <[email protected]>
I believe the usual form is "Reported-by:".
Thanks,
Miklos