I have begun doing work with OpenBIOS. I was wondering if it is possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what Linux distro should I use? Any advice would really help.
Le vendredi 21 août 2009 à 17:57 -0400, G 3 a écrit :
I have begun doing work with OpenBIOS. I was wondering if it is possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what Linux distro should I use? Any advice would really help.
I don't know if it is possible to compile it on Mac OS X. Personally I use debian lenny on x86_64 with cross-compiler, but I used to build it on an iBook G4 with debian etch. Regards, Laurent -- --------------------- laurent@vivier.eu ---------------------- "Tout ce qui est impossible reste à accomplir" Jules Verne "Things are only impossible until they're not" Jean-Luc Picard
On Sat, Aug 22, 2009 at 1:35 AM, Laurent Vivier<Laurent@vivier.eu> wrote:
Le vendredi 21 août 2009 à 17:57 -0400, G 3 a écrit :
I have begun doing work with OpenBIOS. I was wondering if it is possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what Linux distro should I use? Any advice would really help.
I don't know if it is possible to compile it on Mac OS X. Personally I use debian lenny on x86_64 with cross-compiler, but I used to build it on an iBook G4 with debian etch.
I'm also using x86_64 with cross-compiler: powerpc-elf-as --version GNU assembler (GNU Binutils) 2.18 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `powerpc-elf'. powerpc-elf-gcc -v Using built-in specs. Target: powerpc-elf Configured with: ../configure --target=powerpc-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4 powerpc-elf-gdb -v GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=powerpc-elf". Configuring for *-elf is easier than *-linux, because then the include files, libgcc, crt0.o etc. will not be needed. These can be difficult to compile sometimes. The drawback is that you can't use the compiler for normal Unix programs, only for OpenBIOS and maybe Linux kernel. BTW, there is a bug in one of the tools (binutils, gcc, gdb, can't remember which): if you want the tool for powerpc64, the only supported target is powerpc64-linux, powerpc64-elf won't work. This is not a problem for OpenBIOS because the same binary can be used for both 32 and 64 bit CPUs.
Am 22.08.2009 um 14:16 schrieb Blue Swirl:
Configuring for *-elf is easier than *-linux, because then the include files, libgcc, crt0.o etc. will not be needed. These can be difficult to compile sometimes. The drawback is that you can't use the compiler for normal Unix programs, only for OpenBIOS and maybe Linux kernel.
BTW, there is a bug in one of the tools (binutils, gcc, gdb, can't remember which): if you want the tool for powerpc64, the only supported target is powerpc64-linux, powerpc64-elf won't work. [snip]
It's GCC that doesn't know powerpc64-elf or powerpc64-eabi. Does anyone have any pointers how to set up $PREFIX/powerpc-linux/ include etc. without access to a working ppc Linux system? GCC 4.4.5 -- target=powerpc64-linux build is failing during libdecnumber compilation for lack of string.h and stdio.h. Thanks, Andreas
On Sun, Oct 3, 2010 at 10:19 AM, Andreas Färber <andreas.faerber@web.de> wrote:
Am 22.08.2009 um 14:16 schrieb Blue Swirl:
Configuring for *-elf is easier than *-linux, because then the include files, libgcc, crt0.o etc. will not be needed. These can be difficult to compile sometimes. The drawback is that you can't use the compiler for normal Unix programs, only for OpenBIOS and maybe Linux kernel.
BTW, there is a bug in one of the tools (binutils, gcc, gdb, can't remember which): if you want the tool for powerpc64, the only supported target is powerpc64-linux, powerpc64-elf won't work.
[snip]
It's GCC that doesn't know powerpc64-elf or powerpc64-eabi.
Does anyone have any pointers how to set up $PREFIX/powerpc-linux/include etc. without access to a working ppc Linux system? GCC 4.4.5 --target=powerpc64-linux build is failing during libdecnumber compilation for lack of string.h and stdio.h.
Perhaps you can extract the headers from a RPM with cpio or from a DEB with ar. In theory, adding powerpc64-elf support to GCC should be a matter of adding a target Makefile fragment (t-elf64) to gcc/config/rs6000, maybe some other small changes.
Am 03.10.2010 um 16:07 schrieb Blue Swirl:
In theory, adding powerpc64-elf support to GCC should be a matter of adding a target Makefile fragment (t-elf64) to gcc/config/rs6000, maybe some other small changes.
Here's what I tried so far based on the 4.4 branch and t-linux64: diff --git a/gcc/config.gcc b/gcc/config.gcc index 6f72224..794655a 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -1816,6 +1816,14 @@ powerpc-*-elf*) extra_options="${extra_options} rs6000/sysv4.opt" tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t- ppcgas rs6000/t-ppccomm" ;; +powerpc64-*-elf*) + tm_file="${tm_file} dbxelf.h elfos.h usegas.h svr4.h freebsd- spec.h rs6000/sysv4.h" + test x$with_cpu != x || cpu_is_64bit=yes + test x$cpu_is_64bit != xyes || tm_file="${tm_file} rs6000/ default64.h" + tm_file="rs6000/biarch64.h ${tm_file}" + extra_options="${extra_options} rs6000/sysv4.opt" + tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t- ppcgas rs6000/t-ppccomm rs6000/t-elf64" + ;; powerpc-*-eabialtivec*) tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/eabialtivec.h" extra_options="${extra_options} rs6000/sysv4.opt" diff --git a/gcc/config/rs6000/t-elf64 b/gcc/config/rs6000/t-elf64 new file mode 100644 index 0000000..b95a291 --- /dev/null +++ b/gcc/config/rs6000/t-elf64 @@ -0,0 +1,26 @@ + +#rs6000/t-elf64 + +LIB2FUNCS_EXTRA += tramp.S $(srcdir)/config/rs6000/ppc64-fp.c \ + $(srcdir)/config/rs6000/darwin-ldouble.c +LIB2FUNCS_EXTRA := $(sort $(LIB2FUNCS_EXTRA)) + +TARGET_LIBGCC2_CFLAGS += -mno-minimal-toc + +# On Debian, Ubuntu and other derivative distributions, the 32bit libraries +# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to +# /lib and /usr/lib, while other distributions install libraries into /lib64 +# and /usr/lib64. The LSB does not enforce the use of /lib64 and / usr/lib64, +# it doesn't tell anything about the 32bit libraries on those systems. Set +# MULTILIB_OSDIRNAMES according to what is found on the target. + +MULTILIB_OPTIONS = m64/m32 msoft-float +MULTILIB_DIRNAMES = 64 32 nof +MULTILIB_EXTRA_OPTS = fPIC mstrict-align +MULTILIB_EXCEPTIONS = m64/msoft-float +MULTILIB_EXCLUSIONS = m64/!m32/msoft-float +MULTILIB_OSDIRNAMES = ../lib64 ../lib nof +MULTILIB_MATCHES = $(MULTILIB_MATCHES_FLOAT) + +softfp_wrap_start := '\#ifndef __powerpc64__' +softfp_wrap_end := '\#endif' Result: Configuring in powerpc64-elf/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking build system type... powerpc-apple-darwin9.8.0 checking host system type... powerpc64-unknown-elf checking for powerpc64-elf-ar... /Users/andreas/QEMU/OpenBIOS/bin/ powerpc64-elf/bin/ar checking for powerpc64-elf-lipo... powerpc64-elf-lipo checking for powerpc64-elf-nm... /Users/andreas/QEMU/OpenBIOS/gcc- ppc64/./gcc/nm checking for powerpc64-elf-ranlib... /Users/andreas/QEMU/OpenBIOS/bin/ powerpc64-elf/bin/ranlib checking for powerpc64-elf-strip... /Users/andreas/QEMU/OpenBIOS/bin/ powerpc64-elf/bin/strip checking whether ln -s works... yes checking for powerpc64-elf-gcc... /Users/andreas/QEMU/OpenBIOS/gcc- ppc64/./gcc/xgcc -B/Users/andreas/QEMU/OpenBIOS/gcc-ppc64/./gcc/ -B/ Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/bin/ -B/Users/andreas/ QEMU/OpenBIOS/bin/powerpc64-elf/lib/ -isystem /Users/andreas/QEMU/ OpenBIOS/bin/powerpc64-elf/include -isystem /Users/andreas/QEMU/ OpenBIOS/bin/powerpc64-elf/sys-include checking for suffix of object files... configure: error: in `/Users/ andreas/QEMU/OpenBIOS/gcc-ppc64/powerpc64-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make: *** [all] Error 2 Andreas
checking for suffix of object files... configure: error: in `/Users/ andreas/QEMU/OpenBIOS/gcc-ppc64/powerpc64-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details.
Can we see those details? "cannot compute suffix" can be caused by many things. Segher
On Sun, Oct 3, 2010 at 10:36 PM, Andreas Färber <andreas.faerber@web.de> wrote:
Am 03.10.2010 um 16:07 schrieb Blue Swirl:
In theory, adding powerpc64-elf support to GCC should be a matter of adding a target Makefile fragment (t-elf64) to gcc/config/rs6000, maybe some other small changes.
Here's what I tried so far based on the 4.4 branch and t-linux64:
diff --git a/gcc/config.gcc b/gcc/config.gcc index 6f72224..794655a 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -1816,6 +1816,14 @@ powerpc-*-elf*) extra_options="${extra_options} rs6000/sysv4.opt" tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcgas rs6000/t-ppccomm" ;; +powerpc64-*-elf*) + tm_file="${tm_file} dbxelf.h elfos.h usegas.h svr4.h freebsd-spec.h rs6000/sysv4.h" + test x$with_cpu != x || cpu_is_64bit=yes + test x$cpu_is_64bit != xyes || tm_file="${tm_file} rs6000/default64.h" + tm_file="rs6000/biarch64.h ${tm_file}" + extra_options="${extra_options} rs6000/sysv4.opt" + tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcgas rs6000/t-ppccomm rs6000/t-elf64" + ;; powerpc-*-eabialtivec*) tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/eabialtivec.h" extra_options="${extra_options} rs6000/sysv4.opt" diff --git a/gcc/config/rs6000/t-elf64 b/gcc/config/rs6000/t-elf64 new file mode 100644 index 0000000..b95a291 --- /dev/null +++ b/gcc/config/rs6000/t-elf64 @@ -0,0 +1,26 @@ + +#rs6000/t-elf64 + +LIB2FUNCS_EXTRA += tramp.S $(srcdir)/config/rs6000/ppc64-fp.c \ + $(srcdir)/config/rs6000/darwin-ldouble.c +LIB2FUNCS_EXTRA := $(sort $(LIB2FUNCS_EXTRA)) + +TARGET_LIBGCC2_CFLAGS += -mno-minimal-toc + +# On Debian, Ubuntu and other derivative distributions, the 32bit libraries +# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to +# /lib and /usr/lib, while other distributions install libraries into /lib64 +# and /usr/lib64. The LSB does not enforce the use of /lib64 and /usr/lib64, +# it doesn't tell anything about the 32bit libraries on those systems. Set +# MULTILIB_OSDIRNAMES according to what is found on the target. + +MULTILIB_OPTIONS = m64/m32 msoft-float +MULTILIB_DIRNAMES = 64 32 nof +MULTILIB_EXTRA_OPTS = fPIC mstrict-align +MULTILIB_EXCEPTIONS = m64/msoft-float +MULTILIB_EXCLUSIONS = m64/!m32/msoft-float +MULTILIB_OSDIRNAMES = ../lib64 ../lib nof +MULTILIB_MATCHES = $(MULTILIB_MATCHES_FLOAT) + +softfp_wrap_start := '\#ifndef __powerpc64__' +softfp_wrap_end := '\#endif'
Result:
Configuring in powerpc64-elf/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking build system type... powerpc-apple-darwin9.8.0 checking host system type... powerpc64-unknown-elf checking for powerpc64-elf-ar... /Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/bin/ar checking for powerpc64-elf-lipo... powerpc64-elf-lipo checking for powerpc64-elf-nm... /Users/andreas/QEMU/OpenBIOS/gcc-ppc64/./gcc/nm checking for powerpc64-elf-ranlib... /Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/bin/ranlib checking for powerpc64-elf-strip... /Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/bin/strip checking whether ln -s works... yes checking for powerpc64-elf-gcc... /Users/andreas/QEMU/OpenBIOS/gcc-ppc64/./gcc/xgcc -B/Users/andreas/QEMU/OpenBIOS/gcc-ppc64/./gcc/ -B/Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/bin/ -B/Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/lib/ -isystem /Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/include -isystem /Users/andreas/QEMU/OpenBIOS/bin/powerpc64-elf/sys-include checking for suffix of object files... configure: error: in `/Users/andreas/QEMU/OpenBIOS/gcc-ppc64/powerpc64-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make: *** [all] Error 2
This is because the assembly has duplicate labels. I think the other one needs to be changed to a dot prefixed version. I also needed a patch like this for libgcc: --- libgcc/config.host.orig 2010-09-09 22:19:33.000000000 +0000 +++ libgcc/config.host 2010-10-03 20:59:13.000000000 +0000 @@ -480,6 +480,8 @@ powerpc-*-linux* | powerpc64-*-linux*) tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-ldbl128 t-softfp" ;; +powerpc64-*-elf*) + ;; powerpc64-*-gnu*) tmake_file="${tmake_file} rs6000/t-ldbl128 t-softfp" ;; My version of config.gcc is like this: --- gcc/config.gcc.orig 2010-09-24 08:46:36.000000000 +0000 +++ gcc/config.gcc 2010-10-03 21:21:04.000000000 +0000 @@ -2076,6 +2076,11 @@ tm_file="rs6000/secureplt.h ${tm_file}" fi ;; +powerpc64-*-elf*) + tm_file="${tm_file} rs6000/biarch64.h dbxelf.h elfos.h usegas.h svr4.h freebsd-spec.h newlib-stdint.h rs6000/sysv4.h rs6000/default64.h rs6000/elf64.h" + extra_options="${extra_options} rs6000/sysv4.opt" + tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-ppcgas rs6000/t-ppccomm" + ;; powerpc64-*-gnu*) tm_file="${tm_file} elfos.h svr4.h freebsd-spec.h gnu.h rs6000/sysv4.h rs6000/default64.h rs6000/linux64.h rs6000/gnu.h glibc-stdint.h" extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt" This file is referenced above: --- /dev/null 2010-10-04 17:44:52.508000002 +0000 +++ gcc/config/rs6000/elf64.h 2010-10-03 21:45:01.000000000 +0000 @@ -0,0 +1,6 @@ +#define DOT_SYMBOLS 1 +#undef DEFAULT_ABI +#define DEFAULT_ABI ABI_AIX + +#undef TARGET_64BIT +#define TARGET_64BIT 1 libgcc compilation still fails: /src/gcc/gcc-4.6-20100925/obj-amd64-powerpc64-elf/./gcc/xgcc -B/src/gcc/gcc-4.6-20100925/obj-amd64-powerpc64-elf/./gcc/ -B/usr/local/powerpc64-elf/bin/ -B/usr/local/powerpc64-elf/lib/ -isystem /usr/local/powerpc64-elf/include -isystem /usr/local/powerpc64-elf/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -I../../../libgcc/../libdecnumber/no -I../../../libgcc/../libdecnumber -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c ../../../libgcc/../gcc/libgcc2.c \ /tmp/ccvqatNH.s: Assembler messages: /tmp/ccvqatNH.s:22: Error: symbol `.__negdi2' is already defined Looking at the assembler file, this is indeed the case: .file "libgcc2.c" .section ".got","aw" .section ".text" .section .debug_abbrev,"",@progbits .Ldebug_abbrev0: .section .debug_info,"",@progbits .Ldebug_info0: .section .debug_line,"",@progbits .Ldebug_line0: .section ".text" .Ltext0: .align 2 .globl .__negdi2 .section ".opd","aw" .align 3 .__negdi2: .quad .__negdi2,.TOC.@tocbase,0 .previous .size .__negdi2,24 .type ..__negdi2,@function .globl ..__negdi2 .__negdi2:
BTW, there is a bug in one of the tools (binutils, gcc, gdb, can't remember which): if you want the tool for powerpc64, the only supported target is powerpc64-linux, powerpc64-elf won't work.
It's not a bug: it actually is not supported. There is no ABI defined for "generic" powerpc64-elf!
It's GCC that doesn't know powerpc64-elf or powerpc64-eabi.
Does anyone have any pointers how to set up $PREFIX/powerpc-linux/include etc. without access to a working ppc Linux system? GCC 4.4.5 --target=powerpc64-linux build is failing during libdecnumber compilation for lack of string.h and stdio.h.
Configure GCC with --disable-decimal-float . For building a "bare-metal" toolchain, without support for any OS or libc, you can use my http://git.infradead.org/users/segher/buildall.git .
In theory, adding powerpc64-elf support to GCC should be a matter of adding a target Makefile fragment (t-elf64) to gcc/config/rs6000, maybe some other small changes.
And define an ABI, maybe not so little work ;-) Segher
On Mon, Oct 4, 2010 at 4:14 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
BTW, there is a bug in one of the tools (binutils, gcc, gdb, can't remember which): if you want the tool for powerpc64, the only supported target is powerpc64-linux, powerpc64-elf won't work.
It's not a bug: it actually is not supported. There is no ABI defined for "generic" powerpc64-elf!
It's GCC that doesn't know powerpc64-elf or powerpc64-eabi.
Does anyone have any pointers how to set up $PREFIX/powerpc-linux/include etc. without access to a working ppc Linux system? GCC 4.4.5 --target=powerpc64-linux build is failing during libdecnumber compilation for lack of string.h and stdio.h.
Configure GCC with --disable-decimal-float .
For building a "bare-metal" toolchain, without support for any OS or libc, you can use my http://git.infradead.org/users/segher/buildall.git .
In theory, adding powerpc64-elf support to GCC should be a matter of adding a target Makefile fragment (t-elf64) to gcc/config/rs6000, maybe some other small changes.
And define an ABI, maybe not so little work ;-)
How about reusing a decent existing ABI? We don't export any binary interfaces, internally the ABI will be used at least by .S files.
How about reusing a decent existing ABI? We don't export any binary interfaces, internally the ABI will be used at least by .S files.
That's what everyone else does: use the linux ABI. Segher
On Tue, Oct 5, 2010 at 7:46 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
How about reusing a decent existing ABI? We don't export any binary interfaces, internally the ABI will be used at least by .S files.
That's what everyone else does: use the linux ABI.
That doesn't work either, make fails with: checking for intptr_t... no checking for uintptr_t... no checking for pid_t... no checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libiberty] Error 1 The configure line was: ./configure --target=powerpc64-linux --enable-targets=powerpc64-linux --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-multilib --disable-decimal-float --disable-libmudflap This is with gcc-4.6-20100925.
Am 05.10.2010 um 21:11 schrieb Blue Swirl:
On Tue, Oct 5, 2010 at 7:46 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
How about reusing a decent existing ABI? We don't export any binary interfaces, internally the ABI will be used at least by .S files.
That's what everyone else does: use the linux ABI.
That doesn't work either, make fails with: checking for intptr_t... no checking for uintptr_t... no checking for pid_t... no checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libiberty] Error 1
The configure line was: ./configure --target=powerpc64-linux --enable-targets=powerpc64-linux --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-multilib --disable-decimal-float --disable-libmudflap
This is with gcc-4.6-20100925.
Got that on 4.4 branch, too. Andreas
Am 05.10.2010 um 22:32 schrieb Andreas Färber:
Am 05.10.2010 um 21:11 schrieb Blue Swirl:
On Tue, Oct 5, 2010 at 7:46 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
How about reusing a decent existing ABI? We don't export any binary interfaces, internally the ABI will be used at least by .S files.
That's what everyone else does: use the linux ABI.
That doesn't work either, make fails with: checking for intptr_t... no checking for uintptr_t... no checking for pid_t... no checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libiberty] Error 1
The configure line was: ./configure --target=powerpc64-linux --enable-targets=powerpc64-linux --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-multilib --disable-decimal-float --disable-libmudflap
This is with gcc-4.6-20100925.
Got that on 4.4 branch, too.
I have 4.2.4 powerpc64-linux-gnu compiled! 4.1.2 failed on Darwin host due to sigaltstack related errors. Andreas
Am 17.10.2010 um 00:57 schrieb Andreas Färber: [snip]
I have 4.2.4 powerpc64-linux-gnu compiled!
Among many other errors I tripped over this: CC target/kernel/primitives.o cc1: warnings being treated as errors In file included from ../kernel/primitives.c:25: ../kernel/internal.c:53: warning: cast from pointer to integer of different size ../kernel/internal.c:53: error: initializer element is not constant ../kernel/internal.c:53: error: (near initialization for 't[2]') Corresponding code is: #ifndef FCOMPILER /* instead of pointing to an explicit 0 variable we * point behind the pointer. */ static ucell t[] = { DOCOL, 0, (ucell)(t+3), 0 }; static ucell *trampoline = t; #endif The warning goes away if I cast to (unsigned long) first, but the initialization error remains. In powerpc-elf-gcc 4.4+ this didn't surface. Suggestions how to fix? Andreas
Andreas Färber wrote:
Corresponding code is:
#ifndef FCOMPILER /* instead of pointing to an explicit 0 variable we * point behind the pointer. */ static ucell t[] = { DOCOL, 0, (ucell)(t+3), 0 }; static ucell *trampoline = t; #endif
The warning goes away if I cast to (unsigned long) first, but the initialization error remains. In powerpc-elf-gcc 4.4+ this didn't surface. Suggestions how to fix?
Andreas
Right. So this code is to ensure that any arbitrarily executed Forth is always executed as part of a word (i.e. execution will always return to the previous point). In order to do this, the trampoline is a synthetic word used to setup a Forth word like this: DOCOL <xt of code/word> <xt of ;> which is roughly equivalent to: : trampoline <name of word> ; Now the xt of ; is unknown until runtime due to dictionary relocation, but in fact ; is just a CFA of 0. Since an xt is a pointer to a Forth word, then <xt of ;> is done sneakily by pointing to an address containing 0 which is the CFA of semis(). Note there is a less sneaky version of this in the code already - see init_trampoline() in bootstrap.c. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Am 18.10.2010 um 13:17 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
Corresponding code is: #ifndef FCOMPILER /* instead of pointing to an explicit 0 variable we * point behind the pointer. */ static ucell t[] = { DOCOL, 0, (ucell)(t+3), 0 }; static ucell *trampoline = t; #endif The warning goes away if I cast to (unsigned long) first, but the initialization error remains. In powerpc-elf-gcc 4.4+ this didn't surface. Suggestions how to fix? Andreas
Right. So this code is to ensure that any arbitrarily executed Forth is always executed as part of a word (i.e. execution will always return to the previous point).
In order to do this, the trampoline is a synthetic word used to setup a Forth word like this:
DOCOL <xt of code/word> <xt of ;>
which is roughly equivalent to:
: trampoline <name of word> ;
Now the xt of ; is unknown until runtime due to dictionary relocation, but in fact ; is just a CFA of 0. Since an xt is a pointer to a Forth word, then <xt of ;> is done sneakily by pointing to an address containing 0 which is the CFA of semis().
Thanks for the explanation.
Note there is a less sneaky version of this in the code already - see init_trampoline() in bootstrap.c.
Yeah, that code looks better; it's being called from main(). From where could I call such initialization code for t in internal.c? I checked every damn occurrence of "t", it's not used elsewhere. Only trampoline[1] seems getting assigned in a few places. An initializer function using GCC attribute magic maybe? Andreas
Andreas Färber wrote:
Thanks for the explanation.
Note there is a less sneaky version of this in the code already - see init_trampoline() in bootstrap.c.
Yeah, that code looks better; it's being called from main(). From where could I call such initialization code for t in internal.c? I checked every damn occurrence of "t", it's not used elsewhere. Only trampoline[1] seems getting assigned in a few places. An initializer function using GCC attribute magic maybe?
Yuck. Maybe load_dictionary() but that's a bit of a stretch? Is this actually legal C, and in fact what you are hitting is a compiler bug? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
participants (6)
-
Andreas Färber -
Blue Swirl -
G 3 -
Laurent Vivier -
Mark Cave-Ayland -
Segher Boessenkool