From: thomas g. <lis...@sp...> - 2001-09-30 13:59:16
|
just tried to build uml on a ppc machine (imac) running mandrake 8.0 ppc ... first problem i ran into was that the five links in include asm-um (the arch dependent ones) pointed still to the i386 ones even after a make mrproper (i took over the uml tree from an i386 machine before) - maybe there is something missing in the makefile ... ok after fixing this i ran into the next problem: gcc -D__KERNEL__ -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -g -U__powerpc__ -D__UM_PPC__ -D__arch_um__ -DSUBARCH=\"ppc\" -DNESTING=0 -D_LARGEFILE64_SOURCE -I/usr/src/uml/linux/arch/um/include -c -o /usr/src/uml/linux/arch/um/main.o /usr/src/uml/linux/arch/um/main.c /usr/src/uml/linux/arch/um/main.c: In function `__wrap_malloc': /usr/src/uml/linux/arch/um/main.c:160: `PAGE_MASK' undeclared (first use in this function) /usr/src/uml/linux/arch/um/main.c:160: (Each undeclared identifier is reported only once /usr/src/uml/linux/arch/um/main.c:160: for each function it appears in.) /usr/src/uml/linux/arch/um/main.c:147: warning: `start' might be used uninitialized in this function make: *** [/usr/src/uml/linux/arch/um/main.o] Error 1 which could be fixed by adding an include of asm/page.h to main.c - but i'm not shure if this is a clean solution or if maybe the ppc headers are not clean ... ok after that i ended up with make: *** No rule to make target `/usr/src/uml/linux/include/asm/arch/rwlock.h', needed by `/usr/src/uml/linux/include/asm/rwlock.h'. Stop. which does not exist in the ppc includes (at least not in my tree :-) so my question is: is there anything special to take care of then using uml on ppc? - is it supposed to compile out of the box? a lot of thanks in advance and keep up the good work! t p.s.: all this is 2.4.10 with uml-2.4.10-3 -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |
From: Chris E. <cem...@ch...> - 2001-09-30 15:47:51
Attachments:
diff1.txt
|
Hi, Sorry that uml/ppc has got out of date again recently! On Sunday, 30 Sep 2001, thomas graichen wrote: > /usr/src/uml/linux/arch/um/main.c:160: `PAGE_MASK' undeclared (first use > in this function) [snip] > which could be fixed by adding an include of asm/page.h to main.c - > but i'm not shure if this is a clean solution or if maybe the ppc > headers are not clean ... ok after that i ended up with That's what I did, and Jeff has said that's fine. There are another couple of small fixes I needed to make, patch attached. Half of the patch is made of quick hacks, so they're not final. > make: *** No rule to make target > `/usr/src/uml/linux/include/asm/arch/rwlock.h', needed by > `/usr/src/uml/linux/include/asm/rwlock.h'. Stop. > > which does not exist in the ppc includes (at least not in my tree :-) Strange. I didn't come across that problem, and I don't have rwlock.h either. I can only suggest trying from a clean (non-i386) tree. > so my question is: is there anything special to take care of then > using uml on ppc? - is it supposed to compile out of the box? It should, but doesn't, especially after some recent UML work. There are unfortunately still a couple of problems with UML on ppc. There's some recently introduced stack handling code which looks like it has endianness issues, which we haven't fixed yet. And signal handling doesn't work quite right since since ppc doesn't trap sigreturn, and we haven't yet worked around it. Feel free to help. :-) Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: thomas g. <lis...@sp...> - 2001-10-02 00:15:10
|
Chris Emerson <cem...@ch...> wrote: > It should, but doesn't, especially after some recent UML work. > There are unfortunately still a couple of problems with UML on ppc. > There's some recently introduced stack handling code which looks like > it has endianness issues, which we haven't fixed yet. And signal > handling doesn't work quite right since since ppc doesn't trap > sigreturn, and we haven't yet worked around it. > Feel free to help. :-) i'll try my best as much as time and skill allows me ... i applied all your patches to a fresh tree (2.4.10-xfs - but the xfs should not make any difference here - at least for i386 it seems to work fine now) plus uml-2.4.10-4 on a ppc and tried to compile it again ... it ended very aerly at: gcc -D__KERNEL__ -I/usr/src/uml/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -g -U__powerpc__ -D__UM_PPC__ -D__arch_um__ -DSUBARCH="ppc" -DNESTING=0 -D_LARGEFILE64_SOURCE -I/usr/src/uml/linux/arch/um/include -Derrno=kernel_errno -fno-omit-frame-pointer -c -o sched.o sched.c In file included from /usr/src/uml/linux/include/asm/arch/hardirq.h:9, from /usr/src/uml/linux/include/asm/hardirq.h:4, from /usr/src/uml/linux/include/linux/interrupt.h:45, from sched.c:27: /usr/src/uml/linux/include/asm/smp.h:7: warning: `smp_processor_id' redefined /usr/src/uml/linux/include/linux/smp.h:81: warning: this is the location of the previous definition /usr/src/uml/linux/include/asm/smp.h:8: warning: `cpu_logical_map' redefined /usr/src/uml/linux/include/linux/smp.h:85: warning: this is the location of the previous definition /usr/src/uml/linux/include/asm/smp.h:11: arguments given to macro `hard_smp_processor_id' make[2]: *** [sched.o] Error 1 about it falls quite often in the whole tree ... any idea? (it's too late now for me to look closer at it - but maybe you have a good startingpoint for me to continue from tomorrow ...) a lot of thanks in advance t -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |
From: Jeff D. <jd...@ka...> - 2001-10-02 02:30:46
|
lis...@sp... said: > In file included from /usr/src/uml/linux/include/asm/arch/hardirq.h:9, > from /usr/src/uml/linux/include/asm/hardirq.h:4, > from /usr/src/uml/linux/include/linux/interrupt.h:45, > from sched.c:27: > /usr/src/uml/linux/include/asm/smp.h:7: warning: `smp_processor_id' > redefined > /usr/src/uml/linux/include/linux/smp.h:81: warning: this is > the location of the previous definition include/asm/arch/hardirq.h is a link to include/asm-ppc/hardirq.h, which unconditionally includes <asm/smp.h>, in contrast to the i386 hardirq.h, which includes it only if CONFIG_SMP is turned on. You can work around this problem by putting #ifdef CONFIG_SMP around include/asm-um/smp.h. Jeff |
From: thomas g. <lis...@sp...> - 2001-10-02 14:52:36
|
Jeff Dike <jd...@ka...> wrote: > lis...@sp... said: >> In file included from /usr/src/uml/linux/include/asm/arch/hardirq.h:9, >> from /usr/src/uml/linux/include/asm/hardirq.h:4, >> from /usr/src/uml/linux/include/linux/interrupt.h:45, >> from sched.c:27: >> /usr/src/uml/linux/include/asm/smp.h:7: warning: `smp_processor_id' >> redefined >> /usr/src/uml/linux/include/linux/smp.h:81: warning: this is >> the location of the previous definition > include/asm/arch/hardirq.h is a link to include/asm-ppc/hardirq.h, which > unconditionally includes <asm/smp.h>, in contrast to the i386 hardirq.h, > which includes it only if CONFIG_SMP is turned on. You can work around > this problem by putting #ifdef CONFIG_SMP around include/asm-um/smp.h. ok - back again ... thanks - i ifdefed it out and now it compiles fine but unfortunately the result is not very promising :-) [root@blueberry linux]# ./linux Segmentation fault (core dumped) [root@blueberry linux]# i think even the backtrace won't help here much [root@blueberry linux]# gdb linux GNU gdb 5.0mdk-14mdk Linux-Mandrake 8.0 ... This GDB was configured as "ppc-mandrake-linux"... (gdb) run Starting program: /usr/src/uml/linux/linux Program received signal SIGSEGV, Segmentation fault. 0xa000a060 in _start () at net_kern.c:393 393 } (gdb) bt #0 0xa000a060 in _start () at net_kern.c:393 #1 0x0 in ?? () (gdb) but maybe this is due to the mentioned 2.4.10 instabilities or ppc problems ... maybe someone has an idea where to start from here ... i also noticed the following /usr/src/uml/linux/include/asm/ptrace.h:8: warning: `pt_regs' redefined /usr/src/uml/linux/include/asm/sigcontext.h:4: warning: this is the location of the previous definition with the following in the sigcontext-ppc.h #define pt_regs sys_pt_regs #include "asm/sigcontext-generic.h" #undef pt_regs is this a workaround for something? (at least it looks a bit hackerish :-) and some other minor thing: i noticed that the symlinks for the various *-ppc.h files in include/asm-um were not readjusted after moving the tree from intel to ppc plus mrproper ... i think the following addition to the mrproper target in arch/um/Makefile rm -f $(SYMLINK_HEADERS) should take care of this t -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |
From: Chris E. <cem...@ch...> - 2001-10-02 16:03:27
|
On Tuesday, 2 Oct 2001, thomas graichen wrote: > [root@blueberry linux]# ./linux > Segmentation fault (core dumped) > [root@blueberry linux]# Doh! > i think even the backtrace won't help here much > > [root@blueberry linux]# gdb linux [snip] > Program received signal SIGSEGV, Segmentation fault. > 0xa000a060 in _start () at net_kern.c:393 > 393 } Do you have debugging symbols compiled in? If not, then a backtrace with the symbols would be more helpful. > i also noticed the following [snip header ick] > is this a workaround for something? (at least it looks a bit > hackerish :-) Yep. We want the UML pt_regs to show through, but most of the rest of the ppc sigcontext.h as-is. If you look through include/asm-um/, you'll see a few of these. I've been meaning to fix the warning, but haven't got around to it yet. Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: thomas g. <lis...@sp...> - 2001-10-03 07:27:19
|
Chris Emerson <cem...@ch...> wrote: >> Program received signal SIGSEGV, Segmentation fault. >> 0xa000a060 in _start () at net_kern.c:393 >> 393 } > Do you have debugging symbols compiled in? If not, then a backtrace > with the symbols would be more helpful. yes - this is already with debugging symbols in :-( t -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |
From: Chris E. <cem...@ch...> - 2001-10-04 07:15:30
|
On Wednesday, 3 Oct 2001, thomas graichen wrote: > Chris Emerson <cem...@ch...> wrote: > > Do you have debugging symbols compiled in? If not, then a backtrace > > with the symbols would be more helpful. > > yes - this is already with debugging symbols in :-( Weird. What's your host kernel version? Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: thomas g. <lis...@sp...> - 2001-10-04 12:14:50
|
Chris Emerson <cem...@ch...> wrote: > On Wednesday, 3 Oct 2001, thomas graichen wrote: >> Chris Emerson <cem...@ch...> wrote: >> > Do you have debugging symbols compiled in? If not, then a backtrace >> > with the symbols would be more helpful. >> >> yes - this is already with debugging symbols in :-( > Weird. What's your host kernel version? 2.4.9-ben0 plus xfs patches (which should not interact with all this) at that time t -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |
From: Jeff D. <jd...@ka...> - 2001-10-02 17:20:15
|
lis...@sp... said: > [root@blueberry linux]# ./linux > Segmentation fault (core dumped) Do you get a decent stack trace when you 'gdb linux core'? > with the following in the sigcontext-ppc.h > #define pt_regs sys_pt_regs > #include "asm/sigcontext-generic.h" > #undef pt_regs > is this a workaround for something? (at least it looks a bit hackerish > :-) I don't know the details of this specific case, but UML uses the headers from the host arch as much as possible. However, different arches do things differently in their headers. To compensate for this, the UML headers occasionally need to change names or undef things in those headers. > i think the > following addition to the mrproper target in arch/um/Makefile > rm -f $(SYMLINK_HEADERS) Yup, thanks. Jeff |
From: thomas g. <lis...@sp...> - 2001-10-03 07:27:20
|
Jeff Dike <jd...@ka...> wrote: > lis...@sp... said: >> [root@blueberry linux]# ./linux >> Segmentation fault (core dumped) > Do you get a decent stack trace when you 'gdb linux core'? unfortunately not :-( t -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |