hi Gcc
iWMMXt/Linux EABI toolchain
Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. I'm using the target xscale-iwmmxt-linux-gnueabi, I've added support for this target to binutils and built a cross linker etc. I've proceeded to add a suitable target in config.gcc which supports EABI, xscale and Linux basing it on the existing arm/linux target and replacing the linux-elf.h file with a modified one based on xscale-elf.h which I've called xscale-linux-elf.h. I then attempted to build a stage1 compiler with "--with-abi=iwmmxt --with-cpu=iwmmxt --with-arch=iwmmxt", but as soon as the build tries to run xgcc I get the error below. It looks like it's getting the types wrong, but I'm very new to GCC internals and I'm not sure where to look. /var/tmp/portage/gcc-4.2.0_alpha20060225/work/build/./gcc/xgcc -B/var/tmp/portage/gcc-4.2.0_alpha20060225/work/build/./gcc/ -B/usr/xscale-iwmmxt-linux-gnueabi/bin/ -B/usr/xscale-iwmmxt-linux-gnueabi/lib/ -isystem /usr/xscale-iwmmxt-linux-gnueabi/include -isystem /usr/xscale-iwmmxt-linux-gnueabi/sys-include -O2 -O2 -O2 -pipe -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/. -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/../include -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/../libcpp/include -I/var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc \ -c /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ./tm.h:17, from /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:70: /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/config/arm/arm.h:108: warning: integer constant is too large for 'long' type ... snip repetition /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:206: warning: integer constant is too large for 'long' type /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:207: error: requested alignment is too large /var/tmp/portage/gcc-4.2.0_alpha20060225/work/gcc-4.2-20060225/gcc/crtstuff.c:234: warning: integer constant is too large for 'long' type ... Steve ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 04:27:48AM +0000, Steven Newbury wrote: > > Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. > I'm > > using the target xscale-iwmmxt-linux-gnueabi, I've added support for this > > target to binutils and built a cross linker etc. > > > > I've proceeded to add a suitable target in config.gcc which supports EABI, > > xscale and Linux basing it on the existing arm/linux target and replacing > the > > linux-elf.h file with a modified one based on xscale-elf.h which I've > called > > xscale-linux-elf.h. > > > > I then attempted to build a stage1 compiler with "--with-abi=iwmmxt > > --with-cpu=iwmmxt --with-arch=iwmmxt", but as soon as the build tries to > run > > xgcc I get the error below. It looks like it's getting the types wrong, > but > > I'm very new to GCC internals and I'm not sure where to look. > > Try just using arm-none-linux-gnueabi and --with-cpu=iwmmxt > --with-arch=iwmmxt; you almost certainly do not want --with-abi=iwmmxt. > > The error you gave suggests that you didn't modify something properly > to handle the xscale-linux-gnueabi target, but arm would work just fine. Thanks for the quick response! I'm sure it seems I like to make hard wok for myself! It gets worse, I'm porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm not concerned about being able to run old binaries. So is using abi=iwmmxt really not what I want? A really bad idea? Steve ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 04:57:03AM +0000, Steven Newbury wrote: > > Thanks for the quick response! > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm > > porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm > not > > concerned about being able to run old binaries. So is using abi=iwmmxt > really > > not what I want? A really bad idea? > > Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. Ah right! I wasn't sure about that, thanks. I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the vendor string is picked up by my ebuild scripts to pass the iwmmxt target flags. Given my objective, am I wrong to try to make a tool chain that targets xscale-iwmmxt-linux-gnueabi specifically or do you just consider it unnecessary effort? Steve ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Paul Brook <[EMAIL PROTECTED]> wrote: > On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote: > > On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote: > > > Thanks for the quick response! > > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm > > > porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm > > > not concerned about being able to run old binaries. So is using > > > abi=iwmmxt really not what I want? A really bad idea? > > > > Absolutely. You want the AAPCS, not Intel's pre-AAPCS ABI. > > Actually, -mabi=iwmmxt is AAPCS based. It's diffferent from the old intel > iwmmxt ABI. > > Having said that, it probably hasn't been tested particularly well, and I > wouldn't advise using it unless you really need it (ie. you know you have > performace sensitive code that makes extensive use of iWMMXt vector types in > function arguments). My project is to build a complete system optimized for iWMMXt. I am expecting to have to do the odd bit of debugging when things break, so I'll be doing the testing..! Steve ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 05:15:07AM +0000, Steven Newbury wrote: > > I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the > vendor > > string is picked up by my ebuild scripts to pass the iwmmxt target flags. > > Given my objective, am I wrong to try to make a tool chain that targets > > xscale-iwmmxt-linux-gnueabi specifically or do you just consider it > unnecessary > > effort? > > I don't think there's any point to the xscale-* triplets nowadays. My reason for using the xscale-* triplets was because of the warning below from gcc/config/arm/t-xscale-elf: # The iWMMXt multilibs are suppressed for now because gcc only # supports generating them with the IWMMXT or AAPCS ABIs, neither of # which is the default. Until GCC can generate code for an iWMMXt # which will work with the default ABI it is not possible to safely # generate these multilibs. # Since I'm not going to be using the default ABI I thought I would be better off adding a specific target since my aim is to produce a complete Linux environment for general use rather than a stand-alone project. That way I could enable the iWMMXt multilibs without worrying about incompatibility with non iWMMXt targets. Perhaps I'd be better off using iwmmxt-*? Steve ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 05:43:53PM +0000, Steven Newbury wrote: > > My reason for using the xscale-* triplets was because of the warning below > from > > gcc/config/arm/t-xscale-elf: > > > > # The iWMMXt multilibs are suppressed for now because gcc only > > # supports generating them with the IWMMXT or AAPCS ABIs, neither of > > # which is the default. Until GCC can generate code for an iWMMXt > > # which will work with the default ABI it is not possible to safely > > # generate these multilibs. > > # > > > > Since I'm not going to be using the default ABI I thought I would be better > off > > adding a specific target since my aim is to produce a complete Linux > > environment for general use rather than a stand-alone project. That way I > > could enable the iWMMXt multilibs without worrying about incompatibility > with > > non iWMMXt targets. Perhaps I'd be better off using iwmmxt-*? > > The comment does not apply to an EABI toolchain, which you are > building. And comments about multilibs don't apply to anything > using --with-cpu; if you're doing that you ought to be using > --disable-multilib anyway. OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc and --disable-multilib. The vendor string is for my build scripts and also will help differentiate the toolchain, is that valid? Steve ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: iWMMXt/Linux EABI toolchain
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2006 at 06:20:53PM +0000, Steven Newbury wrote: > > OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc > and > > --disable-multilib. The vendor string is for my build scripts and also > will > > help differentiate the toolchain, is that valid? > > Yep. I've given this a go. I've successully built a stage1 cross compiler and installed the glibc headers. However, on re-building gcc it fails to link libgcc: ... ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /usr/arm-iwmmxt-linux-gnueabi/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 Any hints? Steve ___ Win a BlackBerry device from O2 with Yahoo!. Enter now. http://www.yahoo.co.uk/blackberry
Re: iWMMXt/Linux EABI toolchain
Hello again Daniel and all! I'm still working on building the iWMMXt/EABI/NPTL toolchain. I've got to the stage where I have everything built upto the final linking of glibc. Sadly despite making a lot of progress and fixing many problems I am now stuck. As I previously discovered the current gcc-trunk will not build glibc with this configuration due to inlining when it should not, so I decided to try 4.1.0. It mostly works though I had to make a few changes to enable my configuration. I have also ended up patching 4.1.0 with the missing ARM EABI changes from trunk while trying to get everthing to work. My current and hopefully final hurdle is attached. The missing symbols are certainly present in the target libc.a, any idea what I need to fix? Using built-in specs. Target: arm-iwmmxt-linux-gnueabi Configured with: /var/tmp/portage/gcc-4.1.0/work/gcc-4.1.0/configure --prefix=/usr --bindir=/usr/arm-iwmmxt-linux-gnueabi/gcc-bin/4.1.0 --includedir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.0/include --datadir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.0 --mandir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.0/man --infodir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.0/include/g++-v4 --host=i686-pc-linux-gnu --target=arm-iwmmxt-linux-gnueabi --build=i686-pc-linux-gnu --disable-altivec --with-arch=iwmmxt --with-cpu=iwmmxt --disable-multilib --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-multilib --disable-libmudflap --enable-java-awt=gtk --enable-shared --enable-threads=posix --enable-languages=c,c++,java --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.0 Steve ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com build.log Description: 988914365-build.log
GCC 4.1.1/4.2.0 build failure with current binutils (iWMMXt)
I have built an EABI/iWMMXt Gentoo based system. The toolchain I used is
modified to add a Linux/EABI/iWMMXt target. It has been fine until I changed
my binutils from an earlier snapshot to a current version Gentoo 2.16.92,
csl-2_17-branch or CVS trunk. Now when attempting to build GCC (on the host) I
get the following error:
gcc -c -O2 -march=iwmmxt -mcpu=iwmmxt -pipe -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute-DHAVE_CONFIG_H -I. -Icp
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/cp
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/../include
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/../libcpp/include
/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/cp/typeck2.c -o
cp/typeck2.o
{standard input}: Assembler messages:
{standard input}:2391: Error: iWMMXt control register expected -- `tmcr
wcgr0,r1'
This occurs if I attempt to build GCC trunk or 4.1.1 and I suspect 4.1.0 but I
haven't tested it.
I have attached my patch for the Linux/EABI/iWMMXt target.
Steve
Send instant messages to your online friends http://uk.messenger.yahoo.com diff -urN gcc-4.1-20060407.orig/gcc/config/arm/iwmmxt-linux-elf.h gcc-4.1-20060407/gcc/config/arm/iwmmxt-linux-elf.h
--- gcc-4.1-20060407.orig/gcc/config/arm/iwmmxt-linux-elf.h 1970-01-01 01:00:00.0 +0100
+++ gcc-4.1-20060407/gcc/config/arm/iwmmxt-linux-elf.h 2006-04-12 19:35:18.140744636 +0100
@@ -0,0 +1,140 @@
+/* Definitions for Intel PXA270 running Linux-based GNU systems using ELF
+ Copyright (C) 1993, 1994, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
+ 2005, 2006
+ Free Software Foundation, Inc.
+ Contributed by Philip Blundell <[EMAIL PROTECTED]>
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published
+ by the Free Software Foundation; either version 2, or (at your
+ option) any later version.
+
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+ License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING. If not, write to
+ the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+ Boston, MA 02110-1301, USA. */
+
+/* elfos.h should have already been included. Now just override
+ any conflicting definitions and add any extras. */
+
+/* Run-time Target Specification. */
+#undef TARGET_VERSION
+#define TARGET_VERSION fputs (" (Intel XScale-iWMMXt ARM GNU/Linux with ELF)", stderr);
+
+#undef TARGET_DEFAULT_FLOAT_ABI
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT (0)
+
+#define SUBTARGET_CPU_DEFAULT TARGET_CPU_iwmmxt
+
+#define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux -p"
+
+/* Note - there are three possible -mfpu= arguments that can be passed to
+ the assembler:
+
+ -mfpu=softvfp This is the default. It indicates thats doubles are
+ stored in a format compatible with the VFP
+ specification. This is the newer double format, whereby
+ the endian-ness of the doubles matches the endian-ness
+ of the memory architecture.
+
+ -mfpu=fpa This is when -mhard-float is specified.
+ [It is not known if any XScale's have been made with
+ hardware floating point support, but nevertheless this
+ is what happens].
+
+ -mfpu=softfpa This is when -msoft-float is specified.
+ This is the normal behavior of other arm configurations,
+ which for backwards compatibility purposes default to
+ supporting the old FPA format which was always big
+ endian, regardless of the endian-ness of the memory
+ system. */
+
+#undef SUBTARGET_EXTRA_ASM_SPEC
+#define SUBTARGET_EXTRA_ASM_SPEC "%{!mcpu=*:-mcpu=iwmmxt} \
+ %{mhard-float:-mfpu=vfp} \
+ %{!mhard-float: %{msoft-float:-mfpu=softfpa;:-mfpu=softvfp}}"
+
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+ { "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
+
+/* Now we define the strings used to build the spec file. */
+#undef LIB_SPEC
+#define LIB_SPEC \
+ "%{pthread:-lpthread} \
+ %{shared:-lc} \
+ %{!shared:%{profile:-lc_p}%{!profile:-lc}}"
+
+/* The native Linux compiler doesn't build if enums are not int sized */
+#undef CC1_SPEC
+#define CC1_SPEC\
+ "%{!fshort-enums:%{!fno-short-enums:-fno-short-enums}} "
+#undef CC1PLUS_SPEC
+#define CC1PLUS_SPEC CC1_SPEC
+
+#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -l
Re: GCC 4.1.1/4.2.0 build failure with current binutils (iWMMXt)
--- Richard Earnshaw <[EMAIL PROTECTED]> wrote: > On Sun, 2006-05-07 at 10:06, Steven Newbury wrote: > > I have built an EABI/iWMMXt Gentoo based system. The toolchain I used is > > modified to add a Linux/EABI/iWMMXt target. It has been fine until I > changed > > my binutils from an earlier snapshot to a current version Gentoo 2.16.92, > > csl-2_17-branch or CVS trunk. Now when attempting to build GCC (on the > host) I > > get the following error: > > If you think there is a bug in the compiler, please file a bugzilla > report. Bugs reported in other ways are just likely to get forgotten > about. > > http://gcc.gnu.org/bugzilla/ > > R. > > OK. Will do. I am however uncertain whether the bug is in binutils or the compiler... Steve ___ Yahoo! Photos NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
