Re: Multiarch paths and toolchain implications
Matthias Klose wrote on 08/02/2010 09:38:49 PM: > On 02.08.2010 21:12, Ulrich Weigand wrote: > > Matthias Klose wrote on 08/02/2010 06:25:58 PM: > > So the problem that is you want to support a setup where a "gcc" driver > > installed from a 4.4.4 build can still call and run a "gnat1" binary > > installed from a 4.4.3 build? That will most likely work. > > No, gnat (4.4.3) has still to work, if gcc (4.4.4) is already installed. OK, where I said "gcc", the same applies also for "gnat", the Ada compiler driver. The reason for why a 4.4.3 gnat would fail if 4.4.4 gcc is installed is that it wouldn't find things like collect2, libgcc, crt*.o etc. Right? > > But it still seems a bit fragile to me; in general, there's no guarantee > > that if you intermix 4.4.4 and 4.4.3 components in that way, everything > > actually works (that's why they use different directories in the first > > place). > > Then I would need to change this internal path with every source change. I > don't see this as fragile as long as it is ensured that we ship with the > different frontends built from the same patchsets/sources. Note that further > restrictions are made by package dependencies. The issues I'm thinking of are things like: suppose the 4.4.4 middle-end adds code that generates calls to some new libgcc library function, which itself was added with the 4.4.4 libgcc. If you now mix-and-match components so that a compiler built from the 4.4.4 sources and using the new middle-end is used together with a libgcc built from the 4.4.3 sources, things will break. It seems that this does not actually occur in the usage model you describe, since you apparently always update the core (libgcc etc.) *first*. I'm not sure if this is actually guaranteed by the package dependencies though. If it is, then I don't see any real problems with that approach ... > > If you want to have separate packages, a cleaner way would appear to be to > > make them fully self-contained, e.g. have them each provide their own > > driver that can be called separately. > > I don't understand that. I don't have a problem with the driver, butwith the > compiler (gnat1). Having the packages self-contained creates > another problem in > that you get file conflicts for files like collect2, various .o files etc. What I was thinking of is along the lines of having gcc-base-4.4.3 and gcc-base-4.4.4 packages that hold the base files (crt*o, libgcc, collect2 ...), such that you can install *multiple* of the base packages at the same time. This way you could have a gcc-4.4.4 (depending on gcc-base-4.4.4) and a gnat-4.4.3 (depending on gcc-base-4.4.3) all installed at the same time. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Bootstrapping cross compiler status
Dnia piątek, 16 lipca 2010 o 16:59:46 Marcin Juszkiewicz napisał(a):
> As you probably know I am working on bootstrapping cross compiler. Process
> is described on https://wiki.linaro.org/CrossCompilers page.
>
> Current status is: nearly done.
I have 12 bugs to be merged but hope to solve it in next week.
If someone wants to bootstrap compiler then I have a new procedure.
1. You need to fetch few branches (select one gcc version):
lp:~hrw/binutils/pkg-ubuntu
lp:~hrw/eglibc/eglibc-2.12-pkg
http://github.com/hrw/debian-pkg-gcc-4.5
http://github.com/hrw/debian-pkg-gcc-4.4
2. Need patches for linux source package:
http://patchwork.ozlabs.org/patch/60732/
http://launchpadlibrarian.net/52688720/0001-linux-add-support-for-building-
selected-stages-of-k.patch
3. Fetch current Ubuntu versions (select gcc-4.4 or gcc-4.5):
apt-get source -o APT::Get::Only-Source=1 linux gcc-4.4 eglibc binutils
4. Apply changes (from branches or patches for linux). This can be more time
consuming.
5. Build "binary-indep" for each component to get -source binary packages.
6. Eglibc requires hack to get unpatched sources in -source package. Apply
attached "eglibc-hack.patch" - should help.
7. Install all -source packages in your system. This will give their debian/
directories which will be re-used during bootstrap.
8. "make all" with attached Makefile
No warranty that it will work for you as I could forget something. If
everything will go fine "build-rootfs" directory will contain cross compiler.
Regards,
--
JID: h...@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
#!/usr/bin/make
VER_LINUX=2.6.35
VER_GCC=4.4.4
VER_GCC_BASE=4.4
VER_EGLIBC=2.12
VER_BINUTILS=2.20.51
CROSS_ARCH=armel
CROSS_GNU_TYPE = $(shell dpkg-architecture -a${CROSS_ARCH} -qDEB_HOST_GNU_TYPE)
HOST_GNU_TYPE = $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
# taken from gcc packaging
define unpack_tarball
@case $1 in \
*.bz2) tar -x --bzip2 -f $1;; \
*.gz) tar -x --gzip -f $1;; \
*.lzma) lzcat $1 | tar -x -f -;; \
*.xz) xzcat $1 | tar -x -f -;; \
*) false; \
esac
endef
info:
echo ${VER_BINUTILS}
echo ${VER_GCC}
echo ${VER_GCC_BASE}
echo ${VER_EGLIBC}
echo ${CROSS_ARCH}
echo ${CROSS_GNU_TYPE}
echo ${HOST_GNU_TYPE}
init_dirs:
mkdir build-rootfs -p
stamp-init-linux:
$(call unpack_tarball, /usr/src/linux/linux-source-${VER_LINUX}.tar.bz2)
cp -a /usr/src/linux/debian linux-source-${VER_LINUX}/debian
cp -a /usr/src/linux/debian.master linux-source-${VER_LINUX}/debian.master
cd linux-source-${VER_LINUX} && \
cp debian.master/changelog debian/ && \
cp debian.master/control debian/
touch stamp-init-linux
stamp-build-linux: stamp-init-linux
set -e; \
cd linux-source-${VER_LINUX} ;\
DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -a${CROSS_ARCH}
touch stamp-build-linux
stamp-install-linux: stamp-build-linux init_dirs
dpkg-deb -x linux-libc-dev_2.6.35-9.14_armel.deb build-rootfs
touch stamp-install-linux
stamp-init-binutils:
$(call unpack_tarball, /usr/src/binutils/binutils-${VER_BINUTILS}.tar.xz)
cd binutils-${VER_BINUTILS}* ;\
cp -a /usr/src/binutils/debian/ . ;\
echo ${CROSS_ARCH} > debian/target
touch stamp-init-binutils
stamp-build-binutils: stamp-init-binutils
set -e ;\
cd binutils-${VER_BINUTILS}* ;\
dpkg-buildpackage -b -uc -us -nc
touch stamp-build-binutils
stamp-install-binutils: stamp-build-binutils init_dirs
dpkg-deb -x binutils-$(CROSS_GNU_TYPE)_2.20.51.20100710-1ubuntu2_amd64.deb build-rootfs
touch stamp-install-binutils
stamp-init-gcc:
mkdir gcc -p ; \
cd gcc ; \
ln -sf /usr/src/gcc-4.4/gcc-${VER_GCC}.tar.xz gcc-${VER_GCC}.tar.xz ;\
cp -a /usr/src/gcc-4.4/debian/ . ; \
cp -a /usr/src/gcc-4.4/patches debian/ ; \
echo ${CROSS_ARCH} >debian/target
touch stamp-init-gcc
stamp-build-gcc1: stamp-init-gcc stamp-install-binutils
export PATH=${PWD}/build-rootfs/usr/bin/:${PATH} ;\
export LD_LIBRARY_PATH=${PWD}/build-rootfs/usr/$(HOST_GNU_TYPE)/arm-linux-gnueabi/lib/ ;\
cd gcc && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -d
touch stamp-build-gcc1
stamp-install-gcc1: stamp-build-gcc1
dpkg-deb -x gcc-4.4-arm-linux-gnueabi_4.4.4-8_amd64.deb build-rootfs
dpkg-deb -x cpp-4.4-arm-linux-gnueabi_4.4.4-8_amd64.deb build-rootfs
cd build-rootfs/usr/bin/ ; \
ln -sf arm-linux-gnueabi-gcc-${VER_GCC_BASE} arm-linux-gnueabi-gcc ; \
ln -sf arm-linux-gnueabi-cpp-${VER_GCC_BASE} arm-linux-gnueabi-cpp ; \
ln -sf arm-linux-gnueabi-gcov-${VER_GCC_BASE} arm-linux-gnueabi-gcov
touch stamp-install-gcc1
stamp-build-gcc2: stamp-init-gcc stamp-install-eglibc1
export PATH=${PWD}/build-rootfs/usr/bin/:${PATH} ;\
export LD_LIBRARY_PATH=${PWD}/build-rootfs/usr/$(HOST_GNU_TYPE)/arm-linux-gnueabi/lib/ ;\
cd gcc && WITH_BUILD_SYSROOT=${PWD}/build-rootfs DEB_STAGE=stage2 dpkg-buildpackage -b -uc -us -d
touch stamp-build-gcc2
stamp-install-gcc2: stamp-build-gcc2
dpkg-deb -x gcc-4.4-arm-linux-gnueabi_4.4.4-8_amd64.deb build-rootfs
dpk
Re: [gnu-linaro-tools] LP:602190 & LP:602285
Send it again to linaro-toolchain@lists.linaro.org
On Wed, Aug 04, 2010 at 10:53:46PM +0800, Yao Qi wrote:
> LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and
> LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are
> related to this patch below. You can get more details from comments
> of these bugs, since I've added my understand of the cause in
> comments.
>
> This patch is to improve the performance of generated code, however,
> these two bugs are related to this patch(, correct me if I am wrong).
> Now, we have two options, 1) revert this patch, and make these test
> case pass; 2) keep this patch and fix test cases, 3) fix bugs and keep
> this patch,
>
> What do you think?
>
>
> 2009-08-26 Daniel Jacobowitz
>
> Issue #6131 - Enable additional optimizations by default in Lite
> Issue #6103 - Reduce default unrolling parameters at -O3
>
> * release-notes-csl.xml (Improved optimization for ARM): New note.
>
> gcc/
> * config/arm/arm.c (arm_override_options): If flag_unroll_loops has
> the default value, adjust unrolling parameters.
> (arm_optimization_options): Set flag_unroll_loops to a default value.
> Enable flag_promote_loop_indices.
>
> Modified: gcc/config/arm/arm.c
> ==
> --- gcc/config/arm/arm.c (original)
> +++ gcc/config/arm/arm.c Fri Aug 28
> 14:41:19 2009
> @@ -55,6 +55,7 @@
> #include "langhooks.h"
> #include "df.h"
> #include "intl.h"
> +#include "params.h"
>
> /* Forward definitions of types. */
> typedef struct minipool_nodeMnode;
> @@ -1857,6 +1858,29 @@
>warning (0,
> "-low-irq-latency has no effect when compiling for the
> Thumb");
>low_irq_latency = 0;
> +}
> +
> + /* CSL LOCAL */
> + /* Loop unrolling can be a substantial win. At -O2, limit to 2x
> + unrolling by default to prevent excessive code growth; at -O3,
> + limit to 4x unrolling by default. We know we are not optimizing
> + for size if this is set (see arm_optimization_options). */
> + if (flag_unroll_loops == 2)
> +{
> + if (optimize == 2)
> + {
> + flag_unroll_loops = 1;
> + if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES))
> + set_param_value ("max-unroll-times", 2);
> + }
> + else if (optimize > 2)
> + {
> + flag_unroll_loops = 1;
> + if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES))
> + set_param_value ("max-unroll-times", 4);
> + }
> + else
> + flag_unroll_loops = 0;
> }
> }
>
> @@ -21175,6 +21199,17 @@
>set_param_value ("max-inline-insns-single", 1);
>set_param_value ("max-inline-insns-auto", 1);
> }
> + else
> +{
> + /* CSL LOCAL */
> + /* Set flag_unroll_loops to a default value, so that we can tell
> + if it was specified on the command line; see
> + arm_override_options. */
> + flag_unroll_loops = 2;
> + /* Promote loop indices to int where possible. Consider moving this
> + to -Os, also. */
> + flag_promote_loop_indices = 1;
> +}
> }
>
>
> --
> Yao Qi
> CodeSourcery
> y...@codesourcery.com
> (650) 331-3385 x739
--
Yao Qi
CodeSourcery
y...@codesourcery.com
(650) 331-3385 x739
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: LP:602190 & LP:602285
On Wed, Aug 04, 2010 at 10:53:46PM +0800, Yao Qi wrote: > LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and > LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are > related to this patch below. You can get more details from comments > of these bugs, since I've added my understand of the cause in > comments. > > This patch is to improve the performance of generated code, however, > these two bugs are related to this patch(, correct me if I am wrong). > Now, we have two options, 1) revert this patch, and make these test > case pass; 2) keep this patch and fix test cases, 3) fix bugs and keep > this patch, > > What do you think? Julian, weren't you looking at these? You can avoid the param adjustments by an explicit -funroll-loops or -fno-unroll-loops, whichever is appropriate, in the options of the test case. I do not think we should drop the patch. -- Daniel Jacobowitz CodeSourcery ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [gnu-linaro-tools] LP:602190 & LP:602285
On Wed, 4 Aug 2010 22:53:46 +0800 Yao Qi wrote: > LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and > LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are > related to this patch below. You can get more details from comments > of these bugs, since I've added my understand of the cause in > comments. > > This patch is to improve the performance of generated code, however, > these two bugs are related to this patch(, correct me if I am wrong). > Now, we have two options, 1) revert this patch, and make these test > case pass; 2) keep this patch and fix test cases, 3) fix bugs and keep > this patch, > > What do you think? I don't particularly like the "CSL LOCAL" markers in a non-CSL-local branch, but I don't think that's what you're asking :-). We're talking about the Linaro 4.4 branch here, right? I'm planning to add appropriate "-fno-unroll-loops" options to affected tests on the 4.5 branch (that is not done yet), but I wasn't planning to do the same for 4.4. I don't see why we can't though. Julian ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
LP:602190 & LP:602285
LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and
LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are
related to this patch below. You can get more details from comments
of these bugs, since I've added my understand of the cause in
comments.
This patch is to improve the performance of generated code, however,
these two bugs are related to this patch(, correct me if I am wrong).
Now, we have two options, 1) revert this patch, and make these test
case pass; 2) keep this patch and fix test cases, 3) fix bugs and keep
this patch,
What do you think?
2009-08-26 Daniel Jacobowitz
Issue #6131 - Enable additional optimizations by default in Lite
Issue #6103 - Reduce default unrolling parameters at -O3
* release-notes-csl.xml (Improved optimization for ARM): New note.
gcc/
* config/arm/arm.c (arm_override_options): If flag_unroll_loops has
the default value, adjust unrolling parameters.
(arm_optimization_options): Set flag_unroll_loops to a default value.
Enable flag_promote_loop_indices.
Modified: gcc/config/arm/arm.c
==
--- gcc/config/arm/arm.c (original)
+++ gcc/config/arm/arm.c Fri Aug 28
14:41:19 2009
@@ -55,6 +55,7 @@
#include "langhooks.h"
#include "df.h"
#include "intl.h"
+#include "params.h"
/* Forward definitions of types. */
typedef struct minipool_nodeMnode;
@@ -1857,6 +1858,29 @@
warning (0,
"-low-irq-latency has no effect when compiling for the
Thumb");
low_irq_latency = 0;
+}
+
+ /* CSL LOCAL */
+ /* Loop unrolling can be a substantial win. At -O2, limit to 2x
+ unrolling by default to prevent excessive code growth; at -O3,
+ limit to 4x unrolling by default. We know we are not optimizing
+ for size if this is set (see arm_optimization_options). */
+ if (flag_unroll_loops == 2)
+{
+ if (optimize == 2)
+ {
+ flag_unroll_loops = 1;
+ if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES))
+ set_param_value ("max-unroll-times", 2);
+ }
+ else if (optimize > 2)
+ {
+ flag_unroll_loops = 1;
+ if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES))
+ set_param_value ("max-unroll-times", 4);
+ }
+ else
+ flag_unroll_loops = 0;
}
}
@@ -21175,6 +21199,17 @@
set_param_value ("max-inline-insns-single", 1);
set_param_value ("max-inline-insns-auto", 1);
}
+ else
+{
+ /* CSL LOCAL */
+ /* Set flag_unroll_loops to a default value, so that we can tell
+if it was specified on the command line; see
+arm_override_options. */
+ flag_unroll_loops = 2;
+ /* Promote loop indices to int where possible. Consider moving this
+to -Os, also. */
+ flag_promote_loop_indices = 1;
+}
}
--
Yao Qi
CodeSourcery
y...@codesourcery.com
(650) 331-3385 x739
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
