Re: Partial fix! - Was: Re: [BUG report] UML linux-2.6 latest BK doesn't compile
<i.r.wezeman <at> hetnet.nl>
2006-09-08 22:25:28 GMT
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=um
# CONFIG_GPROF is not set
CONFIG_GCOV=y
#
# 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
err = ptrace(PTRACE_GETFPREGS, pid, 0, exec_fp_regs);
if(err)
panic("check_ptrace : PTRACE_GETFPREGS failed, errno = %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 = %d",
errno);
}
#ifndef JB_PC
#define JB_PC 7
#define JB_RSP 6
#define JB_RBP 1
#endif
void get_thread_regs(union uml_pt_regs *uml_regs, void *buffer)
{
struct __jmp_buf_tag *jmpbuf = 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: linux-kernel-owner <at> vger.kernel.org on behalf of Blaisorblade
Sent: Sun 3/13/2005 9:06 PM
To: user-mode-linux-devel <at> lists.sourceforge.net
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
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:
> blaisorblade <at> yahoo.it 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
RSS Feed