From: Blaisorblade <bla...@ya...> - 2005-02-08 10:23:40
|
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 |
From: Blaisorblade <bla...@ya...> - 2005-02-08 17:38:26
|
On Tuesday 08 February 2005 19:29, Jeff Dike wrote: > ai...@ca... 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 |
From: Jeff D. <jd...@ad...> - 2005-02-08 19:57:19
|
bla...@ya... 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 |
From: Anton A. <ai...@ca...> - 2005-02-14 11:35:49
|
On Tue, 2005-02-08 at 17:22 -0500, Jeff Dike wrote: > bla...@ya... 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/ |
From: Blaisorblade <bla...@ya...> - 2005-02-16 18:28:27
|
On Monday 14 February 2005 12:35, Anton Altaparmakov wrote: > On Tue, 2005-02-08 at 17:22 -0500, Jeff Dike wrote: > > bla...@ya... 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 |
From: Jeff D. <jd...@ad...> - 2005-03-05 17:15:34
|
ai...@ca... 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. |
From: Adrian B. <bu...@st...> - 2005-03-05 18:32:30
|
On Sat, Mar 05, 2005 at 02:45:18PM -0500, Jeff Dike wrote: > ai...@ca... 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 |
From: Blaisorblade <bla...@ya...> - 2005-03-07 19:45:44
|
On Saturday 05 March 2005 20:45, Jeff Dike wrote: > ai...@ca... 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 |
From: Jeff D. <jd...@ad...> - 2005-03-07 21:40:15
|
bla...@ya... 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 |
From: Blaisorblade <bla...@ya...> - 2005-03-14 18:53:32
|
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: > bla...@ya... 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 |
From: <i.r...@he...> - 2006-09-08 22:25:52
|
Hi there. I got a error undefined reference to `__bb_init_func' when compiling uml = with kernel 2.6.17.6, gcc 4.1.1 and glibc-2.4 Done: make clean && make distclean && make allmodconfig ARCH=3Dum # CONFIG_GPROF is not set CONFIG_GCOV=3Dy # # UML-specific options # # CONFIG_MODE_TT is not set # CONFIG_STATIC_LINK is not set CONFIG_MODE_SKAS=3Dy Build: make linux ARCH=3Dum edit file: uml/arch/um/os-Linux/sys-i386/registers.c err =3D ptrace(PTRACE_GETFPREGS, pid, 0, exec_fp_regs); if(err) panic("check_ptrace : PTRACE_GETFPREGS failed, errno =3D %d", errno); } #ifndef JB_PC #define JB_PC 5 #define JB_SP 4 #define JB_BP 3 #endif void get_thread_regs(union uml_pt_regs *uml_regs, void *buffer) Edit file: uml/arch/um/os-Linux/sys-x86_64/registers.c panic("check_ptrace : PTRACE_GETFPREGS failed, errno =3D %d", errno); } #ifndef JB_PC #define JB_PC 7 #define JB_RSP 6 #define JB_RBP 1 #endif=20 void get_thread_regs(union uml_pt_regs *uml_regs, void *buffer) { struct __jmp_buf_tag *jmpbuf =3D buffer; Ending: arch/um/kernel/built-in.o:(__ksymtab+0x238): undefined reference to = `__bb_init_func' arch/um/os-Linux/built-in.o: In function `do_syscall_stub': arch/um/os-Linux/skas/mem.c:63: undefined reference to = `get_safe_registers' arch/um/os-Linux/built-in.o: In function `copy_context_skas0': arch/um/os-Linux/skas/process.c:333: undefined reference to = `get_safe_registers' collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. make: *** [.tmp_kallsyms1.S] Error 1 I see it must be solved. So wat is happend now? Ron Wezeman -----Original Message----- From: lin...@vg... on behalf of Blaisorblade Sent: Sun 3/13/2005 9:06 PM To: use...@li... Cc: Jeff Dike; Anton Altaparmakov; lkml Subject: Re: [uml-devel] Re: Partial fix! - Was: Re: [BUG report] UML = linux-2.6 latest BK doesn't compile =20 Ok, I think I finally solved this problem. A note for Jeff: I forgot to send this email and complained to you = because you=20 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: > bla...@ya... said: > > a) wrong because you say __GNUC_PATCHLEVEL__ > 4 rather than >=3D > 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=20 file. The symbol was referred to by the wrappers inserted by GCC for gprof /=20 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=20 not defined in dynamic libraries - don't know if this is a bug of glibc, = I=20 hope not). What was needed was the addition of another EXPORT_SYMBOL, but it = couldn't be=20 added for everybody because it causes the build to fail for old = compilers=20 which don't export the symbol. And "old compilers" include normal gcc 3.3.4 (I verified this on my = Gentoo=20 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,=20 something strange happened: the build started failing because now GCC=20 requires the GCOV options (-fprofile-arcs -ftest-coverage) even during=20 linking (because the gcov helper functions are now in a separate = library). I=20 said "strange" because the same build succeeded with gcc 3.3.4, and I = didn't=20 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=20 solve this (is it maybe a bug in libc or whatever? I don't know). --=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" = in the body of a message to maj...@vg... More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
From: Blaisorblade <bla...@ya...> - 2006-09-09 09:31:50
|
On Saturday 09 September 2006 00:25, i.r...@he... wrote: > Hi there. > > I got a error undefined reference to `__bb_init_func' when > compiling uml with kernel 2.6.17.6, gcc 4.1.1 and glibc-2.4 Ok, that's new. The below mail is about a very similar problem but with an older Gcc, and since these symbols are provided by gcc, this makes a difference. Try removing from arch/um/kernel/gmon_syms.c these 2 lines: extern void __bb_init_func(void *); EXPORT_SYMBOL(__bb_init_func); and recompiling. Better yet, try if adding the weak attribute like below fixes the problem: extern void __bb_init_func(void *) __attribute__((weak)); EXPORT_SYMBOL(__bb_init_func); Another possible thing to check is what happens with CONFIG_STATIC_LINK=y (edit it by hand and do not enable GPROF for now, that is yet another thing). > Done: make clean && make distclean && make allmodconfig ARCH=um > # CONFIG_GPROF is not set > CONFIG_GCOV=y This results from allmodconfig? Mmpf, that is not so nice (allmodconfig should not result in a debug kernel). Even if allmodconfig is not a _smart_ setting (set to y or m everything). > # > # UML-specific options > # > # CONFIG_MODE_TT is not set > # CONFIG_STATIC_LINK is not set > CONFIG_MODE_SKAS=y > Build: make linux ARCH=um > > > edit file: uml/arch/um/os-Linux/sys-i386/registers.c > Ending: > > arch/um/kernel/built-in.o:(__ksymtab+0x238): undefined reference to > `__bb_init_func' > arch/um/os-Linux/built-in.o: In function `do_syscall_stub': > arch/um/os-Linux/skas/mem.c:63: undefined reference to > `get_safe_registers' > arch/um/os-Linux/built-in.o: In function `copy_context_skas0': > arch/um/os-Linux/skas/process.c:333: undefined reference to > `get_safe_registers' Since it arrives to this point, get_safe_register should be undefined only because of the previous failure. > I see it must be solved. So wat is happend now? > > Ron Wezeman -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Blaisorblade <bla...@ya...> - 2006-09-09 15:30:17
|
On Saturday 09 September 2006 15:39, i.r...@he... wrote: > The 'Try removing' will not work. In all these cases you get a message about `get_safe_registers', i.e. another error; do you get the error about __bb_init_func with the "try removing" thing? Also, it should compile by disabling CONFIG_GCOV (as you know probably), and this option is only for debugging - if it does not compile in that case there's something _very_ strange going on (like if `get_safe_registers' had been removed by hand-editing); anyway this discussion is useful to find the fix to the bug. > So have do the 'Better yet ' with make > clean, make distclean, make allmodconfig ARCH=um and make linux ARCH=um > > Now got the same error after 'Better yet': > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > arch/um/os-Linux/built-in.o: In function `do_syscall_stub': > arch/um/os-Linux/skas/mem.c:63: undefined reference to `get_safe_registers' > arch/um/os-Linux/built-in.o: In function `copy_context_skas0': > arch/um/os-Linux/skas/process.c:333: undefined reference to > `get_safe_registers' collect2: ld returned 1 exit status > KSYM .tmp_kallsyms1.S > nm: '.tmp_vmlinux1': No such file > No valid symbol. > make: *** [.tmp_kallsyms1.S] Error 1 > > error, do: #CONFIG_MODE_TT=y > make clean and make linux ARCH=um > > Now got the same error as with 'Better yet' > > error, do: CONFIG_STATIC_LINK=y > make clean and make linux ARCH=um > > Same error as with 'Better yet' > > error, do: CONFIG_GPROF=y > make clean and make linux ARCH=um > > Same error as with 'Better yet' > > TODO: get_safe_register should be undefined only > because of the previous failure. > > In which to undefine? No, don't undefine it. I was talking about this error message, which I can't explain - I thought it was just a conseguence of the error above. > > arch/um/os-Linux/built-in.o: In function `do_syscall_stub': > > arch/um/os-Linux/skas/mem.c:63: undefined reference to > > `get_safe_registers' > > arch/um/os-Linux/built-in.o: In function `copy_context_skas0': > > arch/um/os-Linux/skas/process.c:333: undefined reference to > > `get_safe_registers' since get_safe_registers is defined in arch/um/os-Linux/sys-i386/registers.c, this error does not make a lot of sense. Make sure you haven't removed the definition by mistake - the other possibility is that file is not linked with the rest, but this would cause also other "undefined reference" errors. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Jeff D. <jd...@ad...> - 2006-09-11 15:29:08
|
On Sat, Sep 09, 2006 at 11:31:36AM +0200, Blaisorblade wrote: > On Saturday 09 September 2006 00:25, i.r...@he... wrote: > > Hi there. > > > > I got a error undefined reference to `__bb_init_func' when > > compiling uml with kernel 2.6.17.6, gcc 4.1.1 and glibc-2.4 Happens to me with -rc6. > Try removing from arch/um/kernel/gmon_syms.c these 2 lines: > > extern void __bb_init_func(void *); > EXPORT_SYMBOL(__bb_init_func); And this seems to fix it. > Better yet, try if adding the weak attribute like below fixes > the problem: > > extern void __bb_init_func(void *) __attribute__((weak)); > EXPORT_SYMBOL(__bb_init_func); And this fixes it even better. Jeff |
From: Blaisorblade <bla...@ya...> - 2006-09-17 18:05:07
|
On Monday 11 September 2006 17:27, Jeff Dike wrote: > On Sat, Sep 09, 2006 at 11:31:36AM +0200, Blaisorblade wrote: > > On Saturday 09 September 2006 00:25, i.r...@he... wrote: > > > Hi there. > > > > > > I got a error undefined reference to `__bb_init_func' when > > > compiling uml with kernel 2.6.17.6, gcc 4.1.1 and glibc-2.4 > > Happens to me with -rc6. > > > Try removing from arch/um/kernel/gmon_syms.c these 2 lines: > > > > extern void __bb_init_func(void *); > > EXPORT_SYMBOL(__bb_init_func); > > And this seems to fix it. > > > Better yet, try if adding the weak attribute like below fixes > > the problem: > > > > extern void __bb_init_func(void *) __attribute__((weak)); > > EXPORT_SYMBOL(__bb_init_func); > > And this fixes it even better. Ok, I expect you to send the final patch, thanks... it should go for 2.6.18 possibly, and since you tested it you have it almost ready. Bye bye -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Anton A. <ai...@ca...> - 2005-02-08 10:41:24
|
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/ |
From: Blaisorblade <bla...@ya...> - 2005-02-08 17:49:50
|
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 |
From: Jeff D. <jd...@ad...> - 2005-02-08 21:30:48
|
bla...@ya... 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 |