[ACTIVITY] Weekly status
== Last week == * Backported the fixes for lp693502, lp710623 and lp710652 to linaro 4.6 and linaro 4.5. Tested and sent merge requests. * Wrote several more ifunc tests, and fixed the bugs they showed up. Found that ARM generates unnecessary dynamic relocs against GOT entries, so fixed that as a prerequisite. Improved the tracking of STB_LOCAL ifuncs, so that they're treated more like STB_GLOBAL. * Submitted a request for R_ARM_IRELATIVE to be added to the ARM EABI. == This week == * More ifunc. I'm away next week (14th-18th) Richard ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 31st January - 4th February
== Linaro GCC 4.5 == Reviewed, tested and merged all the outstanding patches waiting to go into Linaro GCC 4.5. Michael reported that there was a build failure on i686 and amd64. I attempted to reproduce this but my builds completed successfully - very strange. Eventually I found that I had a corrupted checkout and managed to reproduce the problem - thanks bzr! The problem is in Tom's recent changes to stmt.c, so I informed him and backed out the patches, temporarily. Spun the Linaro GCC 4.4 and 4.5 release tarballs and passed them to Michael Hope for final testing. == GCC 4.6 == Tested a more recent version of GCC 4.6 and pushed it to the bazaar repository. Already out of date by the time testing finished of course, but never mind. The number of test failures is greatly reduced. Started another build/test with an even more up-to-date check-out. Begun work merging the 4.5 patches into 4.6. Pushed 1 patch upstream. Got another ready to go, once I've tested it. == Android == Tried to unpick a large patch I was sent that supposedly added Android support to Linaro GCC 4.5. The patch was suspicious from the start because it had large changes to gcc/ChangeLog that clearly backed out the 4.5.2 release. After comparing it against various sources I concluded that it was a 4.6 snapshot from last May with (at least some of) the Linaro patches forward ported, and the release numbers fudged to look like it was 4.5.2 based. This was not terribly helpful - I can't very well backport that into our 4.5 branch! == Upstream GCC == Upstream patches requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Question about big endian
Hi, I'd like to check vzip/vuzp patch in big endian mode. But when I try to compile with -mbig-endian flag, I get > ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon neon-vtrnu8.c > -mbig-endian /home/irar/mainline/bin/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../libgcc_s.so.1: could not read symbols: File in wrong format collect2: ld returned 1 exit status What am I missing? Thanks, Ira ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Question about big endian
On Mon, 7 Feb 2011 17:18:40 +0200
Ira Rosen wrote:
> Hi,
>
> I'd like to check vzip/vuzp patch in big endian mode. But when I try
> to compile with -mbig-endian flag, I get
>
> > ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon
> > neon-vtrnu8.c -mbig-endian
> /home/irar/mainline/bin/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../libgcc_s.so.1:
> could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
>
> What am I missing?
Building for big-endian ARM is Really Hard (IMO) :-). You can't
intermix little-endian and big-endian objects at all, so you either
need an entirely-big-endian compiler, or to build one with
little-endian/big-endian switchable multilibs.
I've attached a little patch which adds hardwired big-endian multilib
configs for ARM EABI and ARM Linux -- though I'm pretty sure I only got
one of those working, and I don't remember which. Using it outside
CodeSourcery's build environment is probably also non-trivial.
Once it works you should be able to build binaries for either
little-endian (default) or big-endian (by adding -mbig-endian). You'll
need a big-endian Newlib/GLIBC/etc. as well... but maybe this is useful
as a starting point.
Anyway, hope that helps a bit...
JulianIndex: gcc/config/arm/linux-eabi.h
===
--- gcc/config/arm/linux-eabi.h (revision 167434)
+++ gcc/config/arm/linux-eabi.h (working copy)
@@ -101,3 +101,8 @@
is used. */
#undef CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END) not_used
+
+#undef SYSROOT_SUFFIX_SPEC
+#define SYSROOT_SUFFIX_SPEC \
+ "%{mbig-endian:/be}"
+
Index: gcc/config/arm/neon.md
===
Index: gcc/config/arm/t-linux-eabi
===
--- gcc/config/arm/t-linux-eabi (revision 167434)
+++ gcc/config/arm/t-linux-eabi (working copy)
@@ -21,8 +21,12 @@ TARGET_LIBGCC2_CFLAGS = -fPIC
# We do not build a Thumb multilib for Linux because the definition of
# CLEAR_INSN_CACHE in linux-gas.h does not work in Thumb mode.
-MULTILIB_OPTIONS =
-MULTILIB_DIRNAMES =
+MULTILIB_OPTIONS = mbig-endian
+MULTILIB_DIRNAMES = be
+MULTILIB_OSDIRNAMES = mbig-endian=!be
+MULTILIB_MATCHES =
+MULTILIB_EXCEPTIONS =
+MULTILIB_ALIASES =
# Use a version of div0 which raises SIGFPE, and a special __clear_cache.
LIB1ASMFUNCS := $(filter-out _dvmd_tls,$(LIB1ASMFUNCS)) _dvmd_lnx _clear_cache
Index: gcc/config/arm/t-arm-elf
===
--- gcc/config/arm/t-arm-elf (revision 167434)
+++ gcc/config/arm/t-arm-elf (working copy)
@@ -31,8 +31,8 @@ LIB1ASMFUNCS += _udivsi3 _divsi3 _umodsi
_arm_floatdidf _arm_floatdisf _arm_floatundidf _arm_floatundisf \
_clzsi2 _clzdi2
-MULTILIB_OPTIONS = marm/mthumb
-MULTILIB_DIRNAMES= arm thumb
+MULTILIB_OPTIONS = marm
+MULTILIB_DIRNAMES= arm
MULTILIB_EXCEPTIONS =
MULTILIB_MATCHES =
@@ -57,9 +57,9 @@ MULTILIB_EXCEPTIONS+= *mthumb/*mfloa
# MULTILIB_DIRNAMES += ep9312
# MULTILIB_EXCEPTIONS += *mthumb/*mcpu=ep9312*
#
-# MULTILIB_OPTIONS += mlittle-endian/mbig-endian
-# MULTILIB_DIRNAMES+= le be
-# MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle
+MULTILIB_OPTIONS += mlittle-endian/mbig-endian
+MULTILIB_DIRNAMES+= le be
+MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle
#
# MULTILIB_OPTIONS+= mhard-float/msoft-float
# MULTILIB_DIRNAMES += fpu soft
Index: gcc/config/arm/t-linux
===
--- gcc/config/arm/t-linux (revision 167434)
+++ gcc/config/arm/t-linux (working copy)
@@ -28,6 +28,9 @@ LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3
# MULTILIB_OPTIONS = mhard-float/msoft-float
# MULTILIB_DIRNAMES = hard-float soft-float
+MULTILIB_OPTIONS += mbig-endian/mlittle-endian
+MULTILIB_DIRNAMES += be le
+
# EXTRA_MULTILIB_PARTS = crtbegin.o crtend.o
# LIBGCC = stmp-multilib
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Question about big endian
On 7 February 2011 18:24, Julian Brown wrote: > On Mon, 7 Feb 2011 17:18:40 +0200 > Ira Rosen wrote: > >> Hi, >> >> I'd like to check vzip/vuzp patch in big endian mode. But when I try >> to compile with -mbig-endian flag, I get >> >> > ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon >> > neon-vtrnu8.c -mbig-endian >> /home/irar/mainline/bin/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../libgcc_s.so.1: >> could not read symbols: File in wrong format >> collect2: ld returned 1 exit status >> >> What am I missing? > > Building for big-endian ARM is Really Hard (IMO) :-). You can't > intermix little-endian and big-endian objects at all, so you either > need an entirely-big-endian compiler, or to build one with > little-endian/big-endian switchable multilibs. > > I've attached a little patch which adds hardwired big-endian multilib > configs for ARM EABI and ARM Linux -- though I'm pretty sure I only got > one of those working, and I don't remember which. Using it outside > CodeSourcery's build environment is probably also non-trivial. > > Once it works you should be able to build binaries for either > little-endian (default) or big-endian (by adding -mbig-endian). You'll > need a big-endian Newlib/GLIBC/etc. as well... but maybe this is useful > as a starting point. > > Anyway, hope that helps a bit... It certainly helps to understand that I don't want to try that fancy both-endians build ;) Is separate big-endian build Really Hard as well? Thanks, Ira > > Julian ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
