starting

[G 3]

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.

[Laurent Vivier]

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

[Blue Swirl]

On Sat, Aug 22, 2009 at 1:35 AM, Laurent Vivier 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.

[Andreas Färber]

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

[Blue Swirl]

On Sun, Oct 3, 2010 at 10:19 AM, Andreas Färber  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.

powerpc64-elf (was: starting)

[Andreas Färber]

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

powerpc64-elf (was: starting)

[Segher Boessenkool]

> 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

powerpc64-elf (was: starting)

[Blue Swirl]

On Sun, Oct 3, 2010 at 10:36 PM, Andreas Färber  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:

[Segher Boessenkool]

> > > 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

[Blue Swirl]

On Mon, Oct 4, 2010 at 4:14 AM, Segher Boessenkool
 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.

[Segher Boessenkool]

> 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

[Blue Swirl]

On Tue, Oct 5, 2010 at 7:46 AM, Segher Boessenkool
 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.

[Andreas Färber]

Am 05.10.2010 um 21:11 schrieb Blue Swirl:
> On Tue, Oct 5, 2010 at 7:46 AM, Segher Boessenkool
>  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

powerpc64 (was: starting)

[Andreas Färber]

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
> >  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

powerpc64 (was: starting)

[Andreas Färber]

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

powerpc64

[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().

Note there is a less sneaky version of this in the code already - see 
init_trampoline() in bootstrap.c.

HTH,

Mark.

powerpc64

[Andreas Färber]

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

powerpc64

[Mark Cave-Ayland]

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.