Hi,
With the current linux-2.6 BK tree I get this when trying to compile
UML:
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/um/kernel/built-in.o(__ksymtab+0x2b0): In function `um_execve':
arch/um/kernel/exec_kern.c:59: undefined reference to `__bb_init_func'
collect2: ld returned 1 exit status
KSYM .tmp_kallsyms1.S
nm: '.tmp_vmlinux1': No such file
/bin/bash: line 1: 26161 Exit 1 nm -n .tmp_vmlinux1
26162 Segmentation fault | scripts/kallsyms >.tmp_kallsyms1.S
make: *** [.tmp_kallsyms1.S] Error 139
This is with SKAS mode enabled and TT disabled. My .config is attached.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Tuesday 08 February 2005 11:09, Anton Altaparmakov wrote:
> Hi,
>
> With the current linux-2.6 BK tree I get this when trying to compile
> UML:
>
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/um/kernel/built-in.o(__ksymtab+0x2b0): In function `um_execve':
> arch/um/kernel/exec_kern.c:59: undefined reference to `__bb_init_func'
> collect2: ld returned 1 exit status
> KSYM .tmp_kallsyms1.S
> nm: '.tmp_vmlinux1': No such file
> /bin/bash: line 1: 26161 Exit 1 nm -n .tmp_vmlinux1
> 26162 Segmentation fault | scripts/kallsyms >.tmp_kallsyms1.S
> make: *** [.tmp_kallsyms1.S] Error 139
>
> This is with SKAS mode enabled and TT disabled. My .config is attached.
Hmm - I do not understand at all where `__bb_init_func' comes from (not from
UML by sure, only from kernel headers possibly). And from preprocessing the
source (of the -bk4 snapshot), nothing similar comes out.
long um_execve(char *file, char * *argv, char * *env)
{
long err;
err = execve1(file, argv, env);
if(!err)
do_longjmp((current_thread_info()->task)->thread.exec_buf, 1);
return(err);
}
make arch/um/kernel/exec_kern.i ARCH=um
grep bb_init arch/um/kernel/exec_kern.i
gives nothing (tested with your config, too).
Try adding a "#undef execve1" before the problematic line, and reporting (here
I don't get the failure).
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
On Tue, 2005-02-08 at 11:22 +0100, Blaisorblade wrote:
> On Tuesday 08 February 2005 11:09, Anton Altaparmakov wrote:
> > Hi,
> >
> > With the current linux-2.6 BK tree I get this when trying to compile
> > UML:
> >
> > CC init/version.o
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > arch/um/kernel/built-in.o(__ksymtab+0x2b0): In function `um_execve':
> > arch/um/kernel/exec_kern.c:59: undefined reference to `__bb_init_func'
> > collect2: ld returned 1 exit status
> > KSYM .tmp_kallsyms1.S
> > nm: '.tmp_vmlinux1': No such file
> > /bin/bash: line 1: 26161 Exit 1 nm -n .tmp_vmlinux1
> > 26162 Segmentation fault | scripts/kallsyms >.tmp_kallsyms1.S
> > make: *** [.tmp_kallsyms1.S] Error 139
> >
> > This is with SKAS mode enabled and TT disabled. My .config is attached.
>
> Hmm - I do not understand at all where `__bb_init_func' comes from (not from
> UML by sure, only from kernel headers possibly). And from preprocessing the
> source (of the -bk4 snapshot), nothing similar comes out.
It is from UML. 'bk -r grep __bb_init_func' gives:
arch/um/kernel/gmon_syms.c 1.1 extern void __bb_init_func(void
*);
arch/um/kernel/gmon_syms.c 1.1 EXPORT_SYMBOL(__bb_init_func);
The kernel compiles fine with the same .config but TT mode also enabled.
So I suspect that in the non-TT case the gmon_syms binary doesn't get
linked into the kernel so the symbol is missing or something like
that...
Also note I am using the latest BK as pulled about an hour ago. I don't
know how old the snapshot you are using is in comparison. Lots of UML
changes were pulled in by my pull...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
[email protected] said:
> arch/um/kernel/exec_kern.c:59: undefined reference to `__bb_init_func'
The __bb_init_func export is to allow modules to be built with a gcov-enabled
UML. I get a bunch of undefines in the module links when I get rid of it.
This is probably being too intimate with libc, and yours probably doesn't have
__bb_init_func.
Try the patch below and see if it helps. Modules won't work, but you should
get a working UML.
Jeff
Index: 2.6.10/arch/um/kernel/Makefile
===================================================================
--- 2.6.10.orig/arch/um/kernel/Makefile 2005-02-07 12:45:56.000000000 -0500
+++ 2.6.10/arch/um/kernel/Makefile 2005-02-08 10:23:31.000000000 -0500
@@ -15,7 +15,6 @@
obj-$(CONFIG_BLK_DEV_INITRD) += initrd.o
obj-$(CONFIG_GPROF) += gprof_syms.o
-obj-$(CONFIG_GCOV) += gmon_syms.o
obj-$(CONFIG_TTY_LOG) += tty_log.o
obj-$(CONFIG_SYSCALL_DEBUG) += syscall_user.o
Index: 2.6.10/arch/um/kernel/gmon_syms.c
===================================================================
--- 2.6.10.orig/arch/um/kernel/gmon_syms.c 2004-12-24 16:35:39.000000000 -0500
+++ 2.6.10/arch/um/kernel/gmon_syms.c 2003-09-15 09:40:47.000000000 -0400
@@ -1,20 +0,0 @@
-/*
- * Copyright (C) 2001, 2002 Jeff Dike ([email protected])
- * Licensed under the GPL
- */
-
-#include "linux/module.h"
-
-extern void __bb_init_func(void *);
-EXPORT_SYMBOL(__bb_init_func);
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only. This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
On Tuesday 08 February 2005 19:29, Jeff Dike wrote:
> [email protected] said:
> > arch/um/kernel/exec_kern.c:59: undefined reference to `__bb_init_func'
>
> The __bb_init_func export is to allow modules to be built with a
> gcov-enabled UML. I get a bunch of undefines in the module links when I
> get rid of it.
>
> This is probably being too intimate with libc, and yours probably doesn't
> have __bb_init_func.
>
> Try the patch below and see if it helps. Modules won't work, but you
> should get a working UML.
Why not simply disable CONFIG_GCOV for him, in this case?
Sorry for my previous answer, I was misleaded by the error message (which
*does not* make sense). And it's the first time anybody sees a such error
message, in my experience, so please post more details about your glibc (and
whether gcov is installed).
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
On Tuesday 08 February 2005 11:40, Anton Altaparmakov wrote:
> On Tue, 2005-02-08 at 11:22 +0100, Blaisorblade wrote:
> > On Tuesday 08 February 2005 11:09, Anton Altaparmakov wrote:
> > > Hi,
> > >
> > > With the current linux-2.6 BK tree I get this when trying to compile
> > > UML:
> > >
> > > CC init/version.o
> > > LD init/built-in.o
> > > LD .tmp_vmlinux1
> > > arch/um/kernel/built-in.o(__ksymtab+0x2b0): In function `um_execve':
> > > arch/um/kernel/exec_kern.c:59: undefined reference to `__bb_init_func'
> > > collect2: ld returned 1 exit status
> > > KSYM .tmp_kallsyms1.S
> > > nm: '.tmp_vmlinux1': No such file
> > > /bin/bash: line 1: 26161 Exit 1 nm -n .tmp_vmlinux1
> > > 26162 Segmentation fault | scripts/kallsyms >.tmp_kallsyms1.S
> > > make: *** [.tmp_kallsyms1.S] Error 139
> > >
> > > This is with SKAS mode enabled and TT disabled. My .config is
> > > attached.
> >
> > Hmm - I do not understand at all where `__bb_init_func' comes from (not
> > from UML by sure, only from kernel headers possibly). And from
> > preprocessing the source (of the -bk4 snapshot), nothing similar comes
> > out.
>
> It is from UML. 'bk -r grep __bb_init_func' gives:
>
> arch/um/kernel/gmon_syms.c 1.1 extern void __bb_init_func(void
> *);
> arch/um/kernel/gmon_syms.c 1.1 EXPORT_SYMBOL(__bb_init_func);
>
> The kernel compiles fine with the same .config but TT mode also enabled.
> So I suspect that in the non-TT case the gmon_syms binary
> linked into the kernel
I think it *is* still linked.
> so the symbol is missing or something like
> that...
Hmm, the difference is likely in the build commands:
1) Simply because the build is dynamic in the non-TT mode case (no idea)
2) bug in Makefiles.... but I didn't see anything strange:
arch/um/Makefile-skas (included only when SKAS mode is enabled):
PROFILE += -pg
CFLAGS-$(CONFIG_GCOV) += -fprofile-arcs -ftest-coverage
CFLAGS-$(CONFIG_GPROF) += $(PROFILE)
LINK-$(CONFIG_GPROF) += $(PROFILE)
the Makefiles were heavily changed, however, recently (after 2.6.10).
> Also note I am using the latest BK as pulled about an hour ago. I don't
> know how old the snapshot you are using is in comparison.
Last daily snapshot, when I posted. (Now we are at -bk5). However I only built
the file on which you saw the warning, not everything.
> Lots of UML
> changes were pulled in by my pull...
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
[email protected] said:
> Why not simply disable CONFIG_GCOV for him, in this case?
Anton presumably turned on CONFIG_GCOV because he wanted to do some profiling...
Jeff
[email protected] said:
> the Makefiles were heavily changed, however, recently (after 2.6.10).
There was a bug in that patch. The fix is:
Index: 2.6.10/arch/um/Makefile
===================================================================
--- 2.6.10.orig/arch/um/Makefile 2005-02-08 12:33:23.000000000 -0500
+++ 2.6.10/arch/um/Makefile 2005-02-08 12:33:23.000000000 -0500
@@ -36,8 +36,8 @@
MAKEFILES-INCL += $(foreach mode,$(um-modes-y),\
$(srctree)/$(ARCH_DIR)/Makefile-$(mode))
-ifneq ($(MAKEFILE-INCL),)
- include $(MAKEFILE-INCL)
+ifneq ($(MAKEFILES-INCL),)
+ include $(MAKEFILES-INCL)
endif
ARCH_INCLUDE := -I$(ARCH_DIR)/include
Jeff
On Tue, 2005-02-08 at 17:22 -0500, Jeff Dike wrote:
> [email protected] said:
> > Why not simply disable CONFIG_GCOV for him, in this case?
>
> Anton presumably turned on CONFIG_GCOV because he wanted to do some profiling...
Yes. I finally found a way to get it to compile. Compiling without TT
mode and WITHOUT static build it still fails with the same problem
(__bb_init_func problem I already reported). But compiling without TT
but WITH static build the __bb_init_func problem goes away but instead I
get a __gcov_init missing symbol in my modules.
Note I have gcc-3.3.4-11 (SuSE 9.2) and it defines __gcov_init. So I
added this as an export symbol and lo and behold the kernel and modules
compiled and I am now up an running with UML and NTFS as a module. (-:
Here is the patch that I used to fix this:
--- ntfs-2.6-devel/arch/um/kernel/gmon_syms.c.old 2005-02-14 11:27:04.789474410 +0000
+++ ntfs-2.6-devel/arch/um/kernel/gmon_syms.c 2005-02-14 11:26:49.191117739 +0000
@@ -8,6 +8,9 @@
extern void __bb_init_func(void *);
EXPORT_SYMBOL(__bb_init_func);
+extern void __gcov_init(void *);
+EXPORT_SYMBOL(__gcov_init);
+
/*
* Overrides for Emacs so that we follow Linus's tabbing style.
* Emacs will notice this stuff at the end of the file and automatically
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Monday 14 February 2005 12:35, Anton Altaparmakov wrote:
> On Tue, 2005-02-08 at 17:22 -0500, Jeff Dike wrote:
> > [email protected] said:
> > > Why not simply disable CONFIG_GCOV for him, in this case?
> >
> > Anton presumably turned on CONFIG_GCOV because he wanted to do some
> > profiling...
>
> Yes. I finally found a way to get it to compile. Compiling without TT
> mode and WITHOUT static build it still fails with the same problem
> (__bb_init_func problem I already reported). But compiling without TT
> but WITH static build the __bb_init_func problem goes away but instead I
> get a __gcov_init missing symbol in my modules.
>
> Note I have gcc-3.3.4-11 (SuSE 9.2) and it defines __gcov_init. So I
> added this as an export symbol and lo and behold the kernel and modules
> compiled and I am now up an running with UML and NTFS as a module. (-:
What do we do for previous GCC, which probably do not define _gcov_init (at
least I guess, since things worked before)? We'll get a "unresolved symbol"
in the kernel linking, I guess (unverified).
It is possible, even if ugly, to $(NM) the relevant libraries to choose what
to do, by adding a -D__EXPORT_GCOV_INIT_ (or even, if we know well, to
indicate the GCC version needed for this).
So, for now, I guess we must defer this to later than 2.6.11...
> Here is the patch that I used to fix this:
>
> --- ntfs-2.6-devel/arch/um/kernel/gmon_syms.c.old 2005-02-14
> 11:27:04.789474410 +0000 +++
> ntfs-2.6-devel/arch/um/kernel/gmon_syms.c 2005-02-14 11:26:49.191117739
> +0000 @@ -8,6 +8,9 @@
> extern void __bb_init_func(void *);
> EXPORT_SYMBOL(__bb_init_func);
>
> +extern void __gcov_init(void *);
> +EXPORT_SYMBOL(__gcov_init);
> +
> /*
> * Overrides for Emacs so that we follow Linus's tabbing style.
> * Emacs will notice this stuff at the end of the file and automatically
>
> Best regards,
>
> Anton
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
[email protected] said:
> Yes. I finally found a way to get it to compile. Compiling without
> TT mode and WITHOUT static build it still fails with the same problem
> (__bb_init_func problem I already reported). But compiling without TT
> but WITH static build the __bb_init_func problem goes away but instead
> I get a __gcov_init missing symbol in my modules.
>
> Note I have gcc-3.3.4-11 (SuSE 9.2) and it defines __gcov_init. So I
> added this as an export symbol and lo and behold the kernel and
> modules compiled and I am now up an running with UML and NTFS as a
> module. (-:
Can you try this patch? It exports either __gcov_init or __bb_init_func
depending on your gcc version.
Jeff
Index: linux-2.6.10/arch/um/kernel/gmon_syms.c
===================================================================
--- linux-2.6.10.orig/arch/um/kernel/gmon_syms.c 2005-02-28 17:22:29.000000000 -0500
+++ linux-2.6.10/arch/um/kernel/gmon_syms.c 2005-03-02 12:19:14.000000000 -0500
@@ -5,8 +5,14 @@
#include "linux/module.h"
+#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 3) || \
+ (__GNUC__ == 3 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ > 4)
+extern void __gcov_init(void *);
+EXPORT_SYMBOL(__gcov_init);
+#else
extern void __bb_init_func(void *);
EXPORT_SYMBOL(__bb_init_func);
+#endif
/*
* Overrides for Emacs so that we follow Linus's tabbing style.
On Sat, Mar 05, 2005 at 02:45:18PM -0500, Jeff Dike wrote:
> [email protected] said:
> > Yes. I finally found a way to get it to compile. Compiling without
> > TT mode and WITHOUT static build it still fails with the same problem
> > (__bb_init_func problem I already reported). But compiling without TT
> > but WITH static build the __bb_init_func problem goes away but instead
> > I get a __gcov_init missing symbol in my modules.
> >
> > Note I have gcc-3.3.4-11 (SuSE 9.2) and it defines __gcov_init. So I
> > added this as an export symbol and lo and behold the kernel and
> > modules compiled and I am now up an running with UML and NTFS as a
> > module. (-:
>
> Can you try this patch? It exports either __gcov_init or __bb_init_func
> depending on your gcc version.
>
> Jeff
>
> Index: linux-2.6.10/arch/um/kernel/gmon_syms.c
> ===================================================================
> --- linux-2.6.10.orig/arch/um/kernel/gmon_syms.c 2005-02-28 17:22:29.000000000 -0500
> +++ linux-2.6.10/arch/um/kernel/gmon_syms.c 2005-03-02 12:19:14.000000000 -0500
> @@ -5,8 +5,14 @@
>
> #include "linux/module.h"
>
> +#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 3) || \
> + (__GNUC__ == 3 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ > 4)
This line has to be something like
( (__GNUC__ == 3 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ >= 4) && \
HEAVILY_PATCHES_SUSE_GCC )
I hope SuSE has added some #define to distinguish what they call
"gcc 3.3.4" from GNU gcc 3.3.4 ...
> +extern void __gcov_init(void *);
> +EXPORT_SYMBOL(__gcov_init);
> +#else
> extern void __bb_init_func(void *);
> EXPORT_SYMBOL(__bb_init_func);
> +#endif
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
[email protected] said:
> a) wrong because you say __GNUC_PATCHLEVEL__ > 4 rather than >=
Correct, this is now fixed.
> b) wrong because for he the link failed on __bb_init_func at the
> beginning. So in the case you need to export BOTH symbols.
Incorrect, the link failure was caused by trying to export __bb_init_func,
which makes a reference to it, which was subsequently not being resolved.
You can't export a symbol which doesn't exist.
Jeff
On Saturday 05 March 2005 20:45, Jeff Dike wrote:
> [email protected] said:
> > Yes. I finally found a way to get it to compile. Compiling without
> > TT mode and WITHOUT static build it still fails with the same problem
> > (__bb_init_func problem I already reported). But compiling without TT
> > but WITH static build the __bb_init_func problem goes away but instead
> > I get a __gcov_init missing symbol in my modules.
> >
> > Note I have gcc-3.3.4-11 (SuSE 9.2) and it defines __gcov_init. So I
> > added this as an export symbol and lo and behold the kernel and
> > modules compiled and I am now up an running with UML and NTFS as a
> > module. (-:
>
> Can you try this patch? It exports either __gcov_init or __bb_init_func
> depending on your gcc version.
a) wrong because you say __GNUC_PATCHLEVEL__ > 4 rather than >=
b) wrong because for he the link failed on __bb_init_func at the beginning. So
in the case you need to export BOTH symbols.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
Ok, I think I finally solved this problem.
A note for Jeff: I forgot to send this email and complained to you because you
didn't answer... Sorry Jeff.
However, I explained what I say here to him in chat and we agreed on the fix.
I'm sending this anyway... and I'm attaching the correct fix we discussed.
On Tuesday 08 March 2005 01:10, Jeff Dike wrote:
> [email protected] said:
> > a) wrong because you say __GNUC_PATCHLEVEL__ > 4 rather than >=
> Correct, this is now fixed.
> > b) wrong because for he the link failed on __bb_init_func at the
> > beginning. So in the case you need to export BOTH symbols.
> Incorrect, the link failure was caused by trying to export __bb_init_func,
> which makes a reference to it, which was subsequently not being resolved.
No, the link failure was when linking the first object together in the final
file.
The symbol was referred to by the wrappers inserted by GCC for gprof /
gcov, not by the symbol exporting.
Quoting Anton:
> Yes. I finally found a way to get it to compile. Compiling without TT
> mode and WITHOUT static build it still fails with the same problem
> (__bb_init_func problem I already reported). But compiling without TT
> but WITH static build the __bb_init_func problem goes away but instead I
> get a __gcov_init missing symbol in my modules.
And it was fixed when linking statically, as you see (because the symbol is
not defined in dynamic libraries - don't know if this is a bug of glibc, I
hope not).
What was needed was the addition of another EXPORT_SYMBOL, but it couldn't be
added for everybody because it causes the build to fail for old compilers
which don't export the symbol.
And "old compilers" include normal gcc 3.3.4 (I verified this on my Gentoo
system).
Also, maybe adding a dependency on static linking for GCOV is needed, maybe.
After some successful testing (maybe I didn't test all cases), however,
something strange happened: the build started failing because now GCC
requires the GCOV options (-fprofile-arcs -ftest-coverage) even during
linking (because the gcov helper functions are now in a separate library). I
said "strange" because the same build succeeded with gcc 3.3.4, and I didn't
understand the difference at first.
This required two changes:
- excluding the profiling options from the mk_* utilities.
- adding the GCOV options to linking (this is even documented now). I've
retested that this wasn't needed with gcc 3.3.4 (and I guess older ones).
Finally, I got an unresolved symbol on __bb_fork_func, and I wasn't able to
solve this (is it maybe a bug in libc or whatever? I don't know).
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade