public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: Eric Doenges <doenges@mvtec.com>
To: crossgcc@sourceware.org
Subject: Need a cross compiler for very old PXA270-based system
Date: Tue, 17 Apr 2012 14:07:00 -0000	[thread overview]
Message-ID: <4F8D7903.6040208@mvtec.com> (raw)

Hi,

I have the following problem - a customer wants us to port our software
to their existing embedded system, which uses an Intel PXA270 processor
and runs an ancient Linux (I think it's 2.6.16). The toolchain used for
this system is the 'arm-linux-toolchain-bin-12-15-04-driscoll.tar.gz'.
Unfortunately, a bug in gcc-3.4.3 prevents our software from compiling
correctly, so I need a newer version of gcc that uses the headers and
libraries from the existing toolchain. I also need a newer binutils that
will handle --gc-sections correctly.

My first attempt was to build gcc-4.3.7 and binutils-2.21.1. I
downloaded and unpacked the sources, added symlinks in the gcc source
directory to the binutils directory in order to be able to build
binutils and gcc together, and then used the following configure options:

../gcc-4.3.6/configure --target=arm-linux
--prefix=/home/doenges/opt/pxa270 --with-cpu=iwmmxt --with-arch=iwmmxt
--with-abi=iwmmxt --without-fp --with-float=soft
--enable-cxx-flags=-mcpu=iwmmxt
--with-sysroot=/proj/opt/arm-linux/arm-linux
--with-local-prefix=/proj/opt/arm-linux/arm-linux --disable-nls
--disable-libmudflap --disable-libssp --enable-threads=posix
--enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++
--enable-shared --enable-c99 --enable-long-long --disable-multilib

This fails during building of libgcc due to __DTORS_LIST__ not being
declared. If I change the --target to arm-iwmmxt-linux-gnueabi, it fails
while attempting to link libgcc because gcc will generate Version4 EABI
objects, while the linker expects the old (pre-EABI) ABI. If I leave out
the --with-abi=iwmmxt, it fails much sooner because gcc 4.3.6 refuses to
compile for iwmmxt when not using the new ABI.

Figuring the ABI problem is inherent to gcc 4.x, I then tried to compile
gcc-3.4.6 (again using binutils 2.21.1) using the following configure
options:

../gcc-3.4.6/configure --target=arm-linux
--prefix=/home/doenges/opt/pxa270 --with-cpu=iwmmxt --with-float=soft
--enable-cxx-flags=-mcpu=iwmmxt
--with-headers=/proj/opt/arm-linux/arm-linux/include
--with-local-prefix=/proj/opt/arm-linux/arm-linux --disable-nls
--enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
--without-fp

This also fails during linking of libgcc with the linker complaining
that the object files contain FPA instructions, while the link target
does not. Note that the object files don't actually contain any FPA
instructions; it seems the problem is that the flags in the ELF headers
don't match - objects generated by the compiler have (reported by
readelf -h)

Flags:  0x200, GNU EABI, software FP

while the libraries in the existing toolchain have

Flags:  0x602, has entry point, GNU EABI, software FP, VFP

I have no idea why readelf thinks these are GNU EABI files, as it
reports OS/ABI as 'ARM', with ABI version 0.

I then tried compiling gcc-3.4.3 using the same configure options as in
the original toolchain (obtained by running arm-linux-gcc -v):

../gcc-3.4.3/configure --target=arm-linux
--prefix=/home/doenges/opt/pxa270 --with-cpu=iwmmxt
--enable-cxx-flags=-mcpu=iwmmxt
--with-headers=/proj/opt/arm-linux/arm-linux/include
--with-local-prefix=/proj/opt/arm-linux/arm-linux --disable-nls
--enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
--without-fp

This fails with the same error(s) as gcc 3.4.3, though the object files
created by the compiler now have these flags:

Flags:  0x0

So, to finally get to the point - does anyone have any idea what I must
do to get a working gcc toolchain for the PXA270 using the old ABI ?

With kind regards,
Eric

P.S.: I apologize in advance if this is not the correct mailing list for
this question, but after a fruitless day of googling I'm fresh out of
ideas and don't really know where else to ask.
-- 
Dr. Eric Dönges                            doenges@mvtec.com
MVTec Software GmbH | Neherstr. 1 | 81675 München  | Germany
www.mvtec.com | Tel: +49 89 457695-0 | Fax: +49 89 457695-55
Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

--
For unsubscribe information see http://sourceware.org/lists.html#faq

             reply	other threads:[~2012-04-17 14:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 14:07 Eric Doenges [this message]
2012-04-17 19:07 ` Martin Guy
2012-04-18  8:42   ` Eric Doenges

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F8D7903.6040208@mvtec.com \
    --to=doenges@mvtec.com \
    --cc=crossgcc@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).