Le 25/01/2016 18:08, BALATON Zoltan a écrit :
On Mon, 25 Jan 2016, Laurent Vivier wrote:
$ ./config/scripts/switch-arch ppc64 Configuring OpenBIOS on ppc64 for ppc64 Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok. Creating target config.mak...ok. Creating target rules.mak...ok. Creating config files...ok. [laurent@pmacg5-1 openbios]$ make Building OpenBIOS for ppc64 Building... error: HOSTCC host/kernel/dict.o HOSTCC host/kernel/bootstrap.o HOSTCC host/kernel/forth.o HOSTCC host/kernel/stack.o HOSTCC forthstrap GEN bootstrap.dict panic: segmentation violation at 0x87a1062c dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file rules.mak:69: recipe for target 'bootstrap.dict' failed make[1]: *** [bootstrap.dict] Error 1 make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64' Makefile:19: recipe for target 'build' failed make: *** [build] Error 1
Does running 'make V=1' reveal more errors? Or maybe you could check bootstrap.dict-console.log or some other console.log files if they are created for some more clues whay it fails.
There isn't more detail with V=1
With gdb: Program received signal SIGSEGV, Segmentation fault. findword (s1=0x10007b80 "(semis)") at /home/laurent/Projects/openbios/kernel/dict.c:118 118 tmplfa = read_ucell(cell2pointer(tmplfa));
(gdb) whatis tmplfa type = ucell (gdb) whatis ucell type = uint32_t
and in include/kernel/stack.h:
#ifdef NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH
static inline ucell pointer2cell(const void* x) { return (ucell)(uintptr_t)x; }
static inline void* cell2pointer(ucell x) { return (void*)(uintptr_t)x; }
#endif
So I guess using an uint32_t to store a pointer on a 64bit machine can cause some troubles.
I have no "include/arch/ppc64/types.h", is that normal ?
64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
Can you try with gcc 4.x? 5.x could be stricter that might cause problems but of course best would be if that could be fixed.
Regards, BALATON Zoltan