About arm choice of toolchain options

Sat Oct 22 01:18:21 UTC 2011

Em 18 de outubro de 2011 17:09, Loïc Minier <loic.minier at linaro.org> escreveu:
> On Tue, Oct 18, 2011, Paulo César Pereira de Andrade wrote:
>>   What is the current state of hardfp toolchain? I ask because softfp,
>> what I earlier considered the most sane engineering option, just builds
>> and works using upstream binutils/gcc, but hardfp requires some
>> hacking; I have been using and building weekly LATEST-4.6 gcc
>> snapshots for quite some time.
>
>  It should be pretty good; if you're having issues with FSF GCC, try
>  Linaro's as we've backported some fixes and speed improvements.
>  Support might be better in 4.6 series than in 4.5 series.

  Thanks. Currently I am using the same spec file for x86 and
arm. But one issue I would like to ask is about openjdk bootstrap.

  I adapted fedora java bootstrap procedure to my gcc build,
that is, on a x86:

-%<-
<<just finished compilation of gcc>>

%if %{with java_build_tar}
find libjava -name \*.h -type f |					\
    xargs grep -l '// DO NOT EDIT THIS FILE - it is machine generated'	\
    > libjava-classes.list
find libjava -name \*.class -type f >> libjava-classes.list
find libjava/testsuite -name \*.jar -type f >> libjava-classes.list
tar cf - -T libjava-classes.list | bzip2 -9				\
    > %{_sourcedir}/libjava-classes-%{version}-%{release}.tar.bz2
%endif
-%<-

and on the arm:

-%<-
<<unpack tarball and enter gcc build directory>>

%if %{with java_bootstrap}
    tar xjf %{SOURCE6}
%endif

<<configure and build>>
-%<-

  And it compiled all the java stuff; now I have:

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7hl-mandriva-linux-gnueabi/4.6.2/lto-wrapper
Target: armv7hl-mandriva-linux-gnueabi
Configured with: ./configure --build=armv7hl-mandriva-linux-gnueabi
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
--libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --x-includes=/usr/include
--x-libraries=/usr/lib --disable-libjava-multilib
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-java-awt=gtk
--enable-gtk-cairo --with-cloog --with-ppl --enable-cloog-backend=ppl
--disable-libquadmath --disable-libquadmath-support --disable-libssp
--disable-libunwind-exceptions --disable-werror --enable-__cxa_atexit
--enable-bootstrap --enable-checking=release
--enable-gnu-unique-object
--enable-languages=c,c++,fortran,java,lto,objc,obj-c++
--enable-linker-build-id --enable-plugin --enable-shared
--enable-threads=posix --with-system-zlib
--with-bugurl=https://qa.mandriva.com/ --with-cpu=cortex-a8
--with-tune=cortex-a8 --with-arch=armv7-a --with-mode=thumb
--with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux
--host=armv7hl-mandriva-linux-gnueabi
--target=armv7hl-mandriva-linux-gnueabi
Thread model: posix
gcc version 4.6.2 20111019 (Mandriva) (GCC)

 This is the first gcc 4.6.2 Release Candidate, the eclipse-ecj.jar is
from a x86 computer (noarch bootstrap package).

  But I think it is completely "booged", for example, the Mandriva
openjdk build is based on the fedora one, but, to get it past of
early stage "rewriting" rhino (another noarch package), it was failing
with an out of bounds exception, so, I changed:

/stage3/rpmbuild/java-1.6.0-openjdk/BUILD/icedtea6-1.9.7/rewriter/com/redhat/rewriter/ClassRewriter.java
like this:

-  private static final boolean DEBUG = false;
+  private static final boolean DEBUG = true;

then, after rebuild, it did print a very large amount of debug,
but worked... (that should have triggered some flush
somewhere) but did not matter much, because I got to a
point where gij would jut core dump, specifically, this
command:

/stage3/rpmbuild/BUILD/icedtea6-1.10.3/bootstrap/jdk1.6.0/bin/java
-Djava.endorsed.dirs=/stage3/rpmbuild/BUILD/icedtea6-1.10.3/bootstrap/jdk1.6.0/lib/endorsed
-classpath /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk.build-ecj/hotspot/outputdir/linux_arm_zero/product/../generated/jvmtifiles
jvmtiGen -IN /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk-ecj/hotspot/src/share/vm/prims/jvmti.xml
-XSL /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk-ecj/hotspot/src/share/vm/prims/jvmtiEnter.xsl
-OUT /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk.build-ecj/hotspot/outputdir/linux_arm_zero/product/../generated/jvmtifiles/jvmtiEnter.cpp
-PARAM interface jvmti

  Since I recently wrote a jit for arm for my "toy" language, and have
a fork (for "playground" hacking) of GNU lightning where I added
support for arm, I was aware of issues with the hardfp abi and
varargs functions (I still need to add support for hardfp to my jit
code, and write a thumb2 jit at some point, but porting a distro
from scratch takes quite some time :-)

  So, sometime ago I saw this email

http://lists.fedoraproject.org/pipermail/arm/2011-August/001732.html

and just did look a bit more to find

http://sourceware.org/ml/libffi-discuss/2011/msg00075.html

  So, I believe I should wait a bit more for things to stabilize for
openjdk I guess? Well, I am only trying to make some experiments
with building java for the sake of completeness, I do not like,
neither use java :-)

  Also, since it is early stages I thought it was OK to "cheat" for
the sake of experimenting, so, for the softfp distro port, I got
java-1.6.0-openjdk running fine after using a java-1.6.0-openjdk-devel
for armv5te. And, also tried to "cheat" as apparently fedora already
have a java-1.6.0-openjdk for armv7hl, e.g. see

http://aph.fedorapeople.org/RPMS/armv7hl/

but that will just crash on my armv7hl build (maybe I need to
add patches to libffi?, not use the one built by gcc?).

  Possibly of useful information, gcj would a few times block,
and the same did happen on softfp. So, when noticing a build
was stuck, I would just run "gstack <pid>" to get it to work;
learned that after attaching gdb to all threads just to find out
that when detaching it would get out of the dead lock.

  I do not know much about openjdk build, or/if it calls varargs
functions with float/double arguments, hope not, or things
are really broken...

> --
> Loïc Minier

Thanks and sorry for the usual long email...
Paulo