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.
Done:
- Linux/stage1 - patch (LP:603087) waits approval from kernel team.
- GCC 4.5/stage[12] - patch (LP:603497) created
In progress:
- eglibc/stage1 builds but needs packaging work
Problems:
- gcc/stage3 (normal full build) fails on shlibs because I do not have
libc6-armel packages installed in system but dpkg-shlibdeps needs them
How to bootstrap cross compiler?
- apt-get source gcc-4.5 eglibc binutils linux-image-2.6.35-8-generic
- copy gcc-4.5 dir to gcc-stage1 gcc-stage2 gcc-stage3
- copy eglibc dir to eglibc-stage1 eglibc-stage2
- fetch and apply my patches from LP:603087 LP:603497 LP:603498
- create directory "sysroot/" and point WITH_SYSROOT and WITH_BUILD_SYSROOT
enviroment variables to it
- cd binutils* && TARGET=armel dpkg-buildpackage -b -uc -us
- cd sysroot && dpkg-deb -x ../binutils-arm*deb .
- export PATH=$PWD/sysroot/usr/bin:$PATH
- export LD_LIBRARY_PATH=$PWD/sysroot/usr/x86_64-linux*/usr/arm*/lib
- cd linux* && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -aarmel
- cd sysroot && dpkg-deb -x ../linux-libc-dev*deb .
- cd gcc-stage1 && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us
- cd sysroot && dpkg-deb -x ../cpp*deb ../gcc*deb .
- cd eglibc-stage1 && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -aarmel
As packaging is not yet done for that step manual copying of debian/tmp-libc/
contents to sysroot dir is needed.
- cd gcc-stage2 && DEB_STAGE=stage2 dpkg-buildpackage -b -uc -us
- cd sysroot && dpkg-deb -x ../cpp*deb ../gcc*deb .
- cd eglibc-stage2 && dpkg-buildpackage -b -uc -us -aarmel
- cd sysroot && dpkg-deb -x ../libc*deb .
- cd gcc-stage3 && dpkg-buildpackage -b -uc -us
Here dpkg-shlibdeps will complain so for that step manual copying of
debian/tmp/ contents to sysroot dir is needed.
sysroot dir will then contain working cross compiler - so far I used it to
compile hello.c and kernel for beagleboard
I did not tested yet building stage3 compiler with sysroot=/ like it should be
for installing it on other systems. But thats future.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
...are available at:
http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99315/
I've also finished reference builds of FSF GCC 4.4.4, 4.5.0, and
4.5.1. According to the GCC testsuite, there are no regressions
between the Linaro and FSF branches and in some ways we're a bit
better:
On x86_64 for FSF 4.5.0 (-) vs linaro-4.5+bzr99315 (+):
=== gcc Summary ===
-# of expected passes 61211
+# of expected passes 61239
+# of unexpected successes 1
-# of expected failures 180
+# of expected failures 179
# of unsupported tests 825
On i686 FSF 4.5.0 vs linaro-4.5+bzr99315:
=== gcc Summary ===
-# of expected passes 62285
+# of expected passes 62309
# of unexpected failures 12
-# of unexpected successes 25
+# of unexpected successes 26
-# of expected failures 192
+# of expected failures 191
# of unsupported tests 533
g++, fortran, and objc are the same between builds.
And, strangely enough, ARM is still building.
-- Michael
Minutes from the Toolchain WG weekly meeting are available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-02
A copy, along with activity reports, follow.
-- Michael
= Monday 2nd August 2010 =
== This month's meetings ==
<<MonthCalendar(WorkingGroups/ToolChain/Meetings,2010,08,,,,WorkingGroups/ToolChain/MeetingTemplate)>>
== Attendees ==
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Name ||<style="text-align:
center;">Email ||<style="text-align: center;">IRC Nick ||
|| Andrew Stubbs || andrew.stubbs(a)linaro.org || ams ||
|| Julian Brown || julian(a)codesourcery.com || jbrown ||
|| Michael Hope || michael.hope(a)linaro.org || michaelh ||
|| Richard Earnshaw || richard.earnshaw(a)arm.com || rearnshaw ||
|| Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand ||
|| Yao Qi || yao.qi(a)linaro.org || yao ||
== Agenda ==
* Review action items from last meeting
* New public call-in number: code 263 441 7169
* Hardware availability
* Next milestone
* Outstanding changes that could be merged
* GCC testsuite failures and what to do about them
* http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.4-93543/logs/armv7l-…
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Blueprint ||<style="text-align:
center;">Assignee ||
|| [[https://blueprints.launchpad.net/gcc-linaro/+spec/initial-4.4|Initial
delivery of Linaro GCC 4.4]] || ams ||
|| [[https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers|Cross
Compiler Packages]] || hrw ||
== Action Items from this Meeting ==
* ACTION: Michael to organise and spread next Monday's call in number
* ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5 is
* ACTION: [[LP:500524]] Ulrich to backport to Linaro 4.4
* ACTION: Test failures: Michael to build FSF 4.4.4 as a baseline
* ACTION: Test failures: Michael to compare FSF and Linaro GCC failures
* ACTION: Test failures: All Linaro GCC failures to be ticketed
* ACTION: LTO check on ARM: Michael to reproduce
* ACTION: Ulrich to write up known GDB work
* ACTION: [[LP:598147]]: Michael to reproduce the test failures
* ACTION: [[LP:398403]]: Andrew to reproduce on his IGEP board (has more RAM)
* ACTION: Michael to make sure merge requests are present for work
that has been done
== Action Items from Previous Meeting ==
* ACTION: Michael to organise and spread next Monday's call in number
* DONE: Michael to re-check release dates and suggest something
* Set to the second Tuesday of each month. Lines up with other
Linaro releases quite well.
* DONE: Michael to rename the intermediate milestone
* Set to 2010.08-0. Created 2010.09-0 for the next.
* DONE: Loic to find the Chrome OS contact name for the records
* DONE: Ulrich to confirm PowerPC approach with Matthias
* Confirmed that reverting the PowerPC changes is OK
== Minutes ==
* Reviewed the action items from the previous meeting
* Reviewed the high-priority tickets
* Merging 4.4.5
* Michael is unhappy with merging for next weeks release unless
4.4.5 comes out in the next few days
* Richard went through the announcements. Last was for 4.4.4 on April 30.
* 4.4.5 is due around now
* Expect that the GCC team are focused on 4.5.1 instead
* ACTION: Richard to ask the GCC developers on IRC what the status
of 4.4.5 is
* [[LP:500524]]
* Ulrich has done upstream in 4.4.5
* A small change, unlikely to cause correctness regressions, may
cause performance regressions
* ACTION: Ulrich to backport to Linaro 4.4
* GCC test suite
* Michael asked what level of failures are acceptable
* Richard said that the FSF GCC has never been completely clean on ARM
* Failures may exist upstream
* In the future, should investigate all and fix
* For now, investigate regressions
* ACTION: Michael to build FSF 4.4.4 as a baseline
* ACTION: Michael to compare FSF and Linaro GCC failures
* ACTION: All Linaro GCC failures to be ticketed
* Regressions marked as 'test regression' with Medium severity
* Existing failures to be marked as 'test failure' with Low severity
* Wiki page [[Toolchain/UbuntuRegressions]] has triage from earlier
* Ulrich noted that fixing [[LP:500524]] in Linaro will overlap with
Ubuntu toolchain maintainer's current 4.4.4+svn patch
* Michael said that it is the responsibility of the Ubuntu
toolchain mainter to manage that
* Linaro will notify them on the change
* Discussed LTO
* Michael sees LTO tests fail on gcc-linaro-4.5 on ARM with
--enable-languages=c,c++
* Assumed it was binutils related
* Ulrich: shouldn't be as GCC does most of the work
* ACTION: Michael to reproduce
* Future work
* Focused on GCC at the moment
* Need medium term plan
* Focused on the core toolchain
* GCC
* Binutils
* GDB
* eglibc
* New hire specialises in qemu and will focus on that
* Multiarch is written up, unsure if we've agreed to do the work
* ACTION: Ulrich to write up known GDB work
* Medium severity tickets
* [[LP:598147]]
* May be three issues in one ticket
* Issues due to hardening, now fixed
* Stack crash due to invalid usage
* Extra test failures
* ACTION: Michael to reproduce the test failures
* [[LP:398403]]
* ACTION: Andrew to reproduce on his IGEP board (has more RAM)
* Ongoing work
* ACTION: Michael to make sure merge requests are present for work
that has been done
--- Yao:
== Linaro GCC 4.4 bug fix ==
* LP:604874.
Tried different set of configure/build options to reproduce
segfaults. Ulrich Weigand finally fixed this bug.
* LP:497295
It is about an ICE on maverick/arm. Reproduced ICE on maverick/x86.
ICE goes awy on linaro gcc, so it is not caused by linaro patches.
Finally, I find it is related to gcc-default-ssp.diff in Ubuntu.
Team decide to leave it as won't fix for 4.4, and get fix from
upstreams in 4.5.
* Issue #3314|LP:602288
Understand previous comments on this issue, and read something on
"address cost" in gcc. Looks like not easy to fix this problem.
* LP:612011|GCC PR45094
Create a patch against PR45094, and tested on ARM/QEMU. Post my
patch to gcc-patches first time in my life. A typo is found in my
patch. I fixed typo and submit a new patch again. Suggested to
run regression test again.
* LP:602285|Issue #5157
This bug is caused by our restrictions to the unrolling times.
Proposed two options to fix this bug. Waiting for the feedback from
the team.
== Misc ==
* Try gnu-checkout/gnu-devel/gnu-test for linaro toolchain
* Read doc on ARM ABI and procedure call standard
== This Week ==
* Get patches to PR45094 approved, and backport it for LP:612011.
* Discuss with team and choose one from two options to fix
LP:602285.
* Other bugs on launchpad.
--- Andrew:
== IGEPv2 ==
Continued with IGEPv2 board bringup. The OS that came with the board
proved inappropriate for creating Ubuntu Maverick chroots, so I looked
to updating the board. The IGEP website has tutorials on how to do
this using a tool called "rootstock".
It didn't take to long to get the board running with a more recent
kernel, but using an Ubuntu Lucid rootfs proved more problematic.
Getting a base system installed is not too hard, but that doesn't have
sshd or any other way to get in, and although serial output works,
serial input is broken, and I don't have a USB keyboard (imagine
that!) so using the video console is no good either.
Solved this problem by rebuilding a new rootfs that did have sshd in
it, and getting that setup right. Then installed all the new software
I wanted, set up a maverick chroot on NFS to work with, and gave Yao
and Chung-Lin access.
All was working well, so I took the SD card out, backed it up,
returned it to the board, and now it won't boot, again! To be
continued ....
== GCC 4.5 ==
Applied the first batch of SourceryG++ GCC 4.5 patches to the Linaro
sources, tested them, found them good, and pushed them to launchpad.
Applied another set of patches, and set them testing.
Marked all the patches in the CodeSourcery patch tracker that I
definitely won't be pushing to Linaro.
== Linaro patch tracker ==
Corresponded with Michael Hope regarding the Linaro patch tracker.
== Other ==
Finished getting the CodeSourcery build system to work with Launchpad,
and the Linaro GCC configurations.
-- Ulrich
== GCC ==
* Analyzed and fixed bug #604874 (Firefox fails to build)
- Fixed upstream (mainline, 4.5.2) as PR c++/45112
- Linaro GCC 4.4 branch merge request pending
* Analyzed and fixed bug #500525 (bootstrap failure in stage3)
- Backported mainline fix to upstream 4.4 branch
* Miscellaneous bug analysis / triage / comments on:
#437726, #608125, #607665, #505829, #600209
* Provided patch to revert CodeSourcery PowerPC changes from
Linaro GCC 4.4 (now merged).
== GDB ==
* Continued looking into GDB 7.2 test suite regressions
* Initial implementation of Thumb-2 support in ARM prologue parsing
== Miscellaneous ==
* Provided write-up of multiarch toolchain implications document
== Infrastructure ==
* Ordered IGEPv2 board
CS has this patch in SG++:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html
This patch improves code size in a useful, target independent way, but
was not committed upstream. It's not clear why. Since the patch does not
belong to CodeSourcery, we can't upstream it ourselves either.
Is that patch a suitable candidate for Linaro GCC?
It is not upstreamable due to copyright issues, but we have a policy
that we can keep such patches, if we wish.
The principle of not letting Linaro and SG++ diverge too far also
suggests keeping it.
Any thoughts? If nobody objects soon I shall merge it in.
Andrew
As already discussed with Loic, CodeSourcery have a GCC patch that
implements a new optimization: -fremove-local-statics.
Essentially, it transforms code like this:
int foo (void) { static int a = 1; return a; }
into this:
int foo (void) { int a = 1; return a; }
Admittedly, if the code is written like that you might argue that the
auther gets what they deserve, but apparently at least one of the EEMBC
benchmarks does have these, so now we all care about it.
This patch was originally submitted, by RedHat, to gcc-patches here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/subjects.html#00982
Some discussion later, they decided it would be better to implement the
optimization using inter-procedural dead store analysis:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01602.html
This doesn't seem to have actually been done. Not yet, anyway.
So basically we're left with this patch that does something we want, but
not in a way that can go upstream. :(
The question is, should I merge this to Linaro, or not? Loic and I
agreed to hold off until I'd done a bit more research and/or tried to
upstream it again, but now I think we need to think again.
Andrew
The agenda for todays call is available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-02
The call will be on the usual code / numbers - I have the conference
code for doing a fully public call, but not the corresponding dial in
numbers.
See you then,
-- Michael
Hi all,
These are approximate instructions for installing Lucid on an IGEPv2. It
uses the kernel recommended on the IGEP site because this supports the
SD card. I'm sure an ubuntu kernel will be fine later. At the end, you
will have an SD card that will boot the IGEPv2 board with no external
intervention or devices.
This recipe is derived from here:
http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution
Andrew
----------------------
sudo apt-get install rootstock uboot-mkimage qemu
[The next step gives you the kernel, initrd, and rootfs all in one.
Ideally I would have it install lxde now, to match the "demo" OS that
came with the board, but I found that it hung. Create minimal install
for now, and install lxde later, once the board is running.]
sudo rootstock --fqdn ubuntu --login jdoe --password letmein --imagesize
2G \
--seed
wget,nano,linux-firmware,wireless-tools,usbutils,openssh-server,openssh-client
--dist lucid \
--serial ttyS2 --components "main universe multiverse" \
--kernel-image
http://www.rcn-ee.net/deb/lucid/v2.6.33.5-l3/linux-image-2.6.33.5-l3_1.0luc…
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n
"Linux" -d vmlinuz-2.6.33.5-l3 uImage
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d
initrd.img-2.6.33.5-l3 uInitrd
cat > boot.source < EOF
fatload mmc 0:1 0x80000000 uImage
fatload mmc 0:1 0x82000000 uInitrd
setenv bootargs vram=12M omapfb.mode=dvi:1280x720MR-16@60
root=/dev/mmcblk0p2 console=ttyS2,115200n8 fixrtc
bootm 0x80000000 0x82000000
EOF
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Boot Script" -d
boot.source boot.ini
[Format the SD card with two paritions, mmcblk0p1 small fat-16 (label
"boot"), and mmcblk0p2 large ext3 (label "rootfs").]
cp uImage uInitrd boot.ini /media/boot
sudo tar xzpf armel-rootfs-<date>.tgz -C /media/rootfs/
ln -s ../init.d/ssh /media/rootfs/etc/rc2.d/S01ssh
[Set up /media/rootfs/etc/network/interfaces - you'll need an "auto
eth0" line and something to go with it]
[Boot the target, log in (jdoe/letmein)]
sudo apt-get install lxde gdm
[Actually, I only installed the lxde desktop so I could run it remotely
using Xnest. If you want a graphical login on the video output, only
then do you need gdm also. Not installing gdm means that Xorg doesn't
start at boot time and eat memory and cycles.]
Minutes from the toolchain working group stand up call are at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-28
-- Michael
== Attendees ==
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Name ||<style="text-align:
center;">Email ||<style="text-align: center;">IRC Nick ||
|| Andrew Stubbs || andrew.stubbs(a)linaro.org || ams ||
|| Chung-Lin Tang || cltang(a)codesourcery.com || cltang ||
|| Julian Brown || julian(a)codesourcery.com || jbrown ||
|| Loïc Minier || loic.minier(a)linaro.org || lool ||
|| Michael Hope || michael.hope(a)linaro.org || michaelh ||
|| Richard Earnshaw || richard.earnshaw(a)arm.com || rearnshaw ||
|| Scott Bambrough || scott.bambrough(a)linaro.org || scottb ||
|| Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand ||
|| Yao Qi || yao.qi(a)linaro.org || yao ||
== Agenda ==
* Stand-up call - progress, what's next, and problems
== Action Items from this Meeting ==
* ACTION: Richard: will send Michael an email on the sync primitives
* ACTION: Richard: will see where the str* assembler routines landed
== Action Items from Previous Meeting ==
== Minutes ==
* Andrew:
* Has received a IGEPv2 board and is trying to get it working
* Having trouble with the maverick chroot
* Modifying the CSL build system to use bzr
* Modifying the CSL build system to try the Ubuntu glibc
* 4.5 merges will start going in soon
* Chung-Lin:
* Looking at hard float
* Working on libffi. Has looked at the internals and has started the port
* Julian:
* Working on porting the 4.4 changes into 4.5
* Also has a IGEPv2 board and is working with Andrew to get it going
* Ulrich:
* Proposed the powerpc revert to doko, who is happy with that approach
* Working with upstream on [[LP:500524]]. Patch should be present in 4.4.5
* To work on the Firefox issue [[LP:604874]]
* Michael:
* Working on a continuous build
* Starting a write-up on patch tracking
* Yao
* Has looked into and reproduced [[LP:604874]]
* Will look into the assembly to see what is going on
* Richard:
* Working on the sync primitives in gcc and their use in eglibc
* ACTION: Will send Michael an email on their use
* Michael: any hand coded mem* or str* that he knows of?
* ACTION: Richard: probably present in CSL eglibc, will investigate
* Problems with the license of - want BSD as they're universal, but
glibc may require LGPL
Next call is on Monday
Hi
As some of you know I am working on cross compiler packages for Ubuntu. Those
of you who know what Emdebian is probably use their repositories for such
stuff. Thats ok - I just want to share with you what my job will bring in near
future and what I have done in last 3 months.
Since 26th April I am working for Canonical as part of Linaro project. Due to
my six years of OpenEmbedded experience I became part of Toolchain Working
Group and started work on packaging. Specification etc are listed on blueprint
page:
https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers
I started with reviewing gcc-4.4/4.5 and binutils packaging rules and merged
them as much as possible to get rid of *-cross.mk files which went bitrot a
bit. As result we got packages with debug versions of libraries, dependencies
are proper and as a bonus we got libmudflap cross compiled in case someone
needs it.
Currently I am working on bootstraping cross compiler without using dpkg-cross
converted packages (aka Emdebian way). I got it working with Ubuntu Maverick
versions and published all required patches in bugs linked to my blueprint.
Maybe it is not easy to recreate but should work when you will try.
To make it possible I also have to alter contents of *-source binary packages
from binutils/eglibc/gcc/linux to have a possibility to reuse their packaging
rules in new $ARCH-cross-compiler package on which I will work in next weeks.
And here I have a problem. How much of debian/ directory should be provided in
*-source binary packages? Minimal set just to be able to call "dpkg-
buildpackage -b" and get wanted output or rather everything just in case?
Why new $ARCH-cross-compiler package instead of Emdebian way? Think about
buildd and how they work - nothing can be done manually there so we need to
automate whole procedure.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
The Toolchain Working Group meeting notes from 2010-07-26 are now available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-26
A copy follows.
-- Michael
= Monday 26th July 2010 =
== This month's meetings ==
<<MonthCalendar(WorkingGroups/ToolChain/Meetings,2010,07,,,,WorkingGroups/ToolChain/MeetingTemplate)>>
== Attendees ==
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Name ||<style="text-align:
center;">Email ||<style="text-align: center;">IRC Nick ||
|| Andrew Stubbs || andrew.stubbs(a)linaro.org || ams ||
|| Chung-Lin Tang || cltang(a)codesourcery.com || cltang ||
|| Julian Brown || julian(a)codesourcery.com || jbrown ||
|| Loïc Minier || loic.minier(a)linaro.org || lool ||
|| Marcin Juszkiewicz || marcin.juszkiewicz(a)linaro.org || hrw ||
|| Michael Hope || michael.hope(a)linaro.org || michaelh ||
|| Scott Bambrough || scott.bambrough(a)linaro.org || scottb ||
|| Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand ||
|| Yao Qi || yao.qi(a)linaro.org || yao ||
== Agenda ==
* Review action items from last meeting
* Feedback on the sprint
* Ideas at [[Internal/MichaelHope/ToolChainMockup]]
* What's next
* Our focus
* Release dates
* Hardware availability and needs
* Benchmark ideas
* Open source ones
* 'Typical' open source projects such as ffmpeg, libtheora
* Closed tests
* Next release
* Blueprint status
* Moving to public phone call
* New starter, Chung-Lin Tang
.
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Blueprint ||<style="text-align:
center;">Assignee ||
|| [[https://blueprints.launchpad.net/gcc-linaro/+spec/initial-4.4|Initial
delivery of Linaro GCC 4.4]] || ams ||
|| [[https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers|Cross
Compiler Packages]] || hrw ||
== Action Items from this Meeting ==
* ACTION: Michael to organise and spread next Monday's call in number
* ACTION: Michael to re-check release dates and suggest something
* ACTION: Michael to rename the intermediate milestone
* ACTION: Loic to find the Chrome OS contact name for the records
* ACTION: Ulrich to confirm PowerPC approach with Matthias
== Action Items from Previous Meeting ==
* DONE: Go to the sprint
* DONE: Loic: announcement for linaro-announce, Andrew and MLH to
review before sending
* DONE: Andrew will create release via the Launchpad milestone page
* DONE: Ulrich to summarise the GDB Thumb 2 issues and post so that
Andrew can see if CSL have already done this.
* CSL agrees that it is a problem and isn't working on it
== Minutes ==
* Reviewed the agenda
* Michael Hope is now the toolchain lead
* Calls will be shifted to a public number starting next Monday
* ACTION: Michael to organise and spread number.
* Went over release dates
* Loic suggested the second Tuesday of every month instead as it
gives the rest of working week to handle problems
* Michael would like to keep close to the FeatureFreeze/FinalRelease
dates so that announcements coincide
* ACTION: Michael to re-check dates and suggest something
* The next release, due in a week, will be skipped due to no
significant changes since last release
* ACTION: Michael to rename milestone
* Hardware availability
* CSL
* i.mx51 in their data centre
* Julian, Andrew: have IGEPv2
* Yao, Chung-Lin: will get hardware
* Loic pointed everyone to the internal hardware availability page
* Ulric: is organising hardware
* Loic wants to investigate using qemu as a buildd host
* Michael will write-up and share his hardware. Everything should
move into the data centre later
* Benchmarks
* Loic noted that we want everything in the open and reproducible,
so prefer freely usable benchmarks
* Don't want trivial benchmarks
* Most commercial benchmarks include the source but have
restrictions on sharing the results
* Michael asked for suggestions on benchmarks
* Michael to look at freely usable benchmarks such as lmbench
* Current tickets
* Yao and Michael will look at Firefox
* Ulrich is investigating the next in the list
* Michael would like to send a weekly 'State of the toolchain' update
* Consumed by linaro-dev, Ubuntu toolchain maintainers, and perhaps
others like Ubuntu kernel maintainers
* Loic suggested via Launchpad news
* Discussed communication with Ubuntu
* All notification to go via Ubuntu toolchain maintainers
* U-T-M has responsibility to pass this downstream
* Loic talked with a developer on Chrome OS
* Interested in trying the toolchain
* Currently plain GCC 4.4.1
* Require something very stable
* ACTION: Loic to find a name for the records
* General want for us to try building Chrome OS using the Linaro toolchain
* PowerPC
* Ulrich talked with Matthias at the end of the sprint
* From a Ubuntu perspective, don't want 4.5 to regress in features vs 4.4
* Revert the 4.4 PowerPC changes, keep SH and MIPS. Ubuntu doesn't
support SH or MIPS so no change
* ACTION: Ulrich to confirm with Matthias
Next call is on Wednesday
The armel build that doko kicked off some time ago has completed. I've
gone through and categorised the different failures and created
tickets as appropriate. Latest results are here:
https://wiki.linaro.org/MichaelHope/Sandbox/BuildFailures
-- Michael
Also available at
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-16
= Friday 16th July 2010 =
== Attendees ==
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Name ||<style="text-align:
center;">Email ||<style="text-align: center;">IRC Nick ||
|| Loïc Minier || loic.minier(a)linaro.org || lool ||
|| Andrew Stubbs || andrew.stubbs(a)linaro.org || ams ||
|| Michael Hope || michael.hope(a)linaro.org || mhope ||
|| Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand ||
|| Yao Qi || yao.qi(a)linaro.org || yao ||
|| Marcin Juszkiewicz || marcin.juszkiewicz(a)linaro.org || hrw ||
== Agenda ==
* Review action items from last meeting
* Personal work plan for the sprint
* Release status
== Action Items from this Meeting ==
* ACTION: (everyone) note down what you plan to do so that others can find you
* ACTION: Loic: announcement for linaro-announce, Andrew and MLH to
review before sending
* ACTION: Andrew will create release via the Launchpad milestone page
* ACTION: Ulrich to summarise and post so that Andrew can see if CSL
have already done this
== Action Items from Previous Meeting ==
* (None)
== Minutes ==
* What do do during the sprint
* See https://wiki.linaro.org/Events/2010-07-PlatformSprint/ToolChainWG
* Group discussion topics in the morning
* Free to make own arrangements
* ACTION: (everyone) note down what you plan to do so that others can find you
* Release status
* doko confirmed that the tarball was OK
* Andrew: nothing known remaining for the release
* ACTION: Loic: announcement for linaro-announce, Andrew and MLH to
review before sending
* ACTION: Andrew will create release via the Launchpad milestone page
* Andrew
* nothing left to do except make things public
* looking at FTBFS issues
* looking at getting the CSL test suite running with Linaro
* Michael
* Still reading, making a list of questions for next week
* Ulrich
* looking into one of the ICE in reload. Andrew also looking.
Ulrich will take over this bug
* GDB build failures: noticed one significant root problem due to
prologue tracing
* GDB understands ARM and Thumb, but not Thumb 2
* Loic: plan for GDB Thumb 2 porting
* ACTION: Ulrich to summarise and post so that Andrew can see if
CSL have already done this
* Specifically gnu-linaro-tools(a)codesourcery.com +
linaro-toolchain(a)list.linaro.org + Pedro Alves + Dan Jacobowitz
* Loic: Ubuntu has a set of detached debug symbols
(http://ddebs.ubuntu.com/) which will help as reduces need for
prologue parsing
* Yao
* merging internal CSL 4.4 patches into 4.5
* looking into Ubuntu FTBFS, trying to reproduce
* Loic: would like a list of done vs remaining to get idea for progress
* Andrew: would prefer to do it in a weekly status report
* Marcin
* Working on the staging of the GCC build
* now combining into a build from scratch
* has stage 1 for most cases
* Loic
* looking at hard float
* interesting case of performance vs specialisation
* discussion with Andrew re: tracking changes upstream. Will
discuss at sprint
-- Michael
Hi Richard,
Am I right in understanding that fsf's primary objection to
-mimplicit-it is the resulting unpredictability of the size of the
assembler output for asm blocks? Note that the assmbler output size
is _already_ unpredictable: what about the variable size of Thumb-2
instructions already, and what about use of assembler directives such
as:
#define nops(count) asm( \
".rept " #count "\n\t"
"nop\n\t"
".endr" \
)
Presumably this will defeat GCC's literal pool placement on any
architecture which has literal pools. Indeed, we can come with an
inexhaustible supply of such cases: it's an inevitable result of the
separation between GCC and the assembler.
If for Thumb-2 I assume we already have a heuristic that attempts to
count the number of instructions and predicts the maximum size of the
asm block as n*4 bytes (where n is the instruction count), would it be
feasible to estimate a bound of n*6 bytes if using -mimplicit-it? Or,
do we dump the literal before the asm block to be on the safe side
(and if so, why doesn't this work equally well when using
-mimplicit-it?)
Re the suggestion that inline asm should be "fixed" to include
explicit IT instructions, do you know a practical way to do this?
My concern is that with GCC -marm, the inline asm is passed as-is to
be interpreted non-unified syntax (for backwards compatibility
purposes), whereas with -march>=armv6t2 -mthumb, the asm is passed
(again as-is) to be interpreted in unified syntax. But with explicit
IT blocks, it's impossible to be compatible with both syntaxes if my
understanding is correct: Am I right in thinking that current GNU as
in non-unified syntax mode, and indeed legacy versions of the tools
will treat the IT instructions as an error and barf? Can you think of
a way of working round this?
The best I can think of right now is ghastly preprocessor stuff along
the lines of
#ifdef __thumb__ /* or more correctly __thumb2__ ? */
#define __asm_it_generic(mnemonic,cond) #mnemonic " " #cond "\n\t"
#else
#define __asm_it_generic(mnemonic,cond) /* expands to nothing */
#endif
#define __it(cond) __asm_it_generic(it,cond)
#define __ite(cond) __asm_it_generic(ite,cond)
/* ... */
asm(
__it(eq)
"moveq r0, #0\n\t"
__ite(eq)
"bleq func1\n\t"
"blne func2\n\t"
);
An alternative, if we are happy to "fix" source packages in a way
which breaks building them with older tools, is to pass unified
assembler assembler in unified syntax too. But that would require
some work in the code gen backend for arm if I understand correctly.
But it's a huge task to port everything and some upstream projects may
not accept the changes at all. My concern is that without some
transitional approach, there's simply too much existing code for this
to be viable.
Do you know when unified assmbler support was introduced in fsf?
Cheers
---Dave
As some of you know I came to Linaro from OpenEmbedded project. In OE we cross
compiled by default and to make it more easy we had one nice addon to gcc.
When host includes were used gcc errored out with "CROSS COMPILE BADNESS:
/usr/include used" style message. Patch is present in metadata:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gcc/gcc-4.4…
no-host-includes.patch
Some time ago replacement was announced on OE mailing list:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/34169
In that thread Khem Raj mentioned -Wno-poison-system-directories which is
available in CSL toolchains.
I would like to get that functionality in our cross compiler as this nicely
shows problems in packages. I got hit by that in eglibc when it fails with:
In file included from ../ports/sysdeps/arm/libc-tls.c:20:0:
../csu/libc-tls.c: In function ‘__libc_setup_tls’:
../csu/libc-tls.c:194:1: error: ‘__ARM_NR_set_tls’ undeclared (first use in
this function)
../csu/libc-tls.c:194:1: note: each undeclared identifier is reported only
once for each function it appears in
just because unistd.h used from host instead from target includes.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Dnia piątek, 16 lipca 2010 o 11:35:30 Michael Hope napisał(a):
> * Marcin
> * Working on the staging of the GCC build
> * now combining into a build from scratch
> * has stage 1 for most cases
I have all stages working. Eglibc/stage1 needs work on packaging.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
[ Resent to linaro-toolchain@. ]
Hey
Sorry for the belated post; please find below the minutes from Monday's
Toolchain Working Group meeting and the activity reports from the
preceding week.
You can find the full meeting notes at
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-12
= Monday 12th July 2010 =
== Agenda ==
* Review action items from last meeting
* New linaro-toolchain mailing-list
* Topics for sprint [[Internal/Events/2010-07-PlatformSprint]]
* Release, version numbers, uploading tarballs
* No meetings next week
* Blueprint status
* Initial delivery of Linaro GCC 4.4
* Cross Compiler Packages
== Action Items from this Meeting ==
* Andrew to propose the triplet change to toolchain upstream
* Andrew to send email to Debian ARM on best triplet
* MLH to pickup perl if pbrook doesn't have a patch by Monday evening UTC
* MLH to write up wants as a toolchain developer/tester
* Marcin to check if xdeb incorrectly produces a package findutils-armel
* Loic to push changes on mysql
== Action Items from Previous Meeting ==
* Loic and Andrew to extend wiki page to track progress of the merging
of Ubuntu patches, assignees etc. DONE
* Loic to setup and run a call on merge workflow with bzr DONE
* Matthias to sort autotools issues with new cell-4.4 Linaro patch or
to ask Ulrich for help :-) DONE
* Marcin to fix -gcc symlink (LP #600927) and update-alternatives
installability issue in his public cross-compiler packages DONE
* Yao to update
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuGCCPatches wiki
page for the issue with ADA support and the patches he merged
* Yao to update
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuRegressions
wiki page for the removal of the license patch DONE
* Loic to create a linaro-toolchain-drivers team which can upload
tarballs PARTIAL Group created, tarball upload currently not working
== Minutes ==
* The linaro-toolchain list for toolchain related chatter; please
subscribe!
* Loic called for sprint topics. See
https://wiki.linaro.org/Events/2010-07-PlatformSprint/ToolChainWG
* Meetings have been cancelled for the week of the sprint
* Mentioned the upcoming hardfp port that Debian is investigating
* Port is too large for Linaro itself
* Toolchain should support - best place to support, easiest to
maintain due to doko
* Better choice for Debian as they may get support from Linaro; won't
from CSL 2010 Lite edition
* Noted that there's disagreement on the Debian triplet and position
of the hf marker. Problem is what is correct vs which is the path
of least resistance.
* ACTION Andrew to propose the triplet change to toolchain upstream?
* Noted that the ARM EABI is a family of ABIs that different vendors
take variants from
* ACTION Andrew to send email to Debian ARM on best triplet
* Milestone issue review
* ACTION MLH to try perl if no progress is made by pbrook
* getfem++ can't be reproduced
* vect/* won't fix
* mysql fix is ugly
* pr9771-1.c MLH to continue or send patch otherwise
* neon triggered by march=armv7a which should have occurred with
Lucid GCC
* Can lower priority if a missed optimisation
* MLH wants help on how to best use the packaging system to do what
he's used to such as
* Build exactly what the Ubuntu PPA will end up as
* Build a cross-compiler to try ARM failures on a fast machine
* Do an incremental build
* Do a non-bootstrap build
* Run the compiler under a debugger
* Use the test compiler to build a package
* ACTION MLH to write up wants
* Andrew has a process to build the tarball and will run the
certification process afterwards
* Loic recommended CSL developers to have local hardware
* Blueprints status
* Initial 4.4 release reviewed. Done except Ada patch. Andrew to
edit whiteboard to note
* Update broken Ubuntu patches
* Loic suggests reviewing Ubuntu patches month to month
* Cross compiler (Marcin)
* Tidying up ugly GCC hacks
* Stage 1 is now clean
* ACTION Marcin to check if xdeb incorrectly produces a package
called findutils-armel
* ACTION Loic to push changes to mysql
* Michael will run Wednesday standup call
Activity reports from preceding week:
= Ulrich Weigand =
== GCC ==
* Resolved merge conflicts between cell-branch.diff and gcc444-linaro.diff
(investigated and fixed additional autoconf-related build issue)
* Investigated bug #602287; resolved as won't-fix for Linaro 4.4
* Started investigating bug #602289
== GDB ==
* Completed build and regression test of GDB 7.2 branch on beagle board
* Started working on hardware-breakpoint-support blueprint
== Education ==
* Continued getting familiar with Debian package build process
* Continued getting familiar with Launchpad infrastructure
* Read ARMv7 Architecture Reference Manual
== Infrastructure ==
* Got remote access to Loic's beagle board
* Started process to acquire IGEPv2 board
= Yao Qi =
== Linaro GCC ==
* Ubuntu patch ada-acats.diff on linaro gcc 4.4.
ada-acats.diff and its dependent patches cause some regression
failures. Spent a lot of time on trying different patch sets to
linoar gcc 4.4, but failures do go away. Checked the build log of
ubuntu gcc, and the same failures are there. We decide to leave
this ubuntu patch.
* Merged 19 ubuntu patches to linaro gcc 4.4.
Learn bzr push/merge/branch/commit. Very good version control tool,
and well-collaborated with launchpad.
* Revert license patch in linaro gcc 4.4.
* Merge CS GCC 4.4 patches to CS GCC 4.5.
Choose three patches from Julian's ARM patch list. Two of them are
committed into CS GCC 4.5. The third is sent to CS internal review.
== Misc ==
* Some meetings on linaro status.
= Andrew Stubbs =
== GCC 4.4 ==
* Continued refining the blueprints. We now have the initial 4.4
toolchain delivery blueprint finalised.
* Entered bugs for each of the test regressions in the Ubuntu GCC vs.
FSF GCC.
* Reviewed Yao's launchpad merge request for the Ubuntu GCC patches.
It was all good, so I approved the request and did the merge.
* Reviewed the ARM test failures to make sure they were what we
anticipated they would be.
* Reviewed some of the Ubuntu patches marked "Needs review". Decided
not to use two, rewrote the third and submitted the new patch for
review. Matthias has now accepted it, and applied it to Debian also.
* Found out how to create gnu-style release tarballs and wrote a
Linaro GCC release procedure document for the wiki.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCCReleaseProcess
== GCC 4.5 ==
* Assisted Yao with his patch porting work, and made sure he had
things to do.
= Loic Minier =
* Repaired Beagleboard to boot again
* Cross-built ncurses; did other xdeb tests
* Added color codes and improved structure of
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuRegressions and
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuGCCPatches
* Discussed armhf port, started
http://wiki.debian.org/ArmHardFloatPort
* Started sprint planning and associated wiki pages
Bye,
--
Loïc Minier
Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but
maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and
when state changes. If we don't do something like this, we'll lose track
of what's submitted, and what isn't.
Thanks
Andrew
Hi, all,
I notice that linaro-gcc is a native compiler on ARM, when I go through
linaro gcc bugs on launchpad. When we fix bugs, shall we configure gcc
as a native compiler on ARM directly, or configure gcc as a cross
compiler on i386 box? Former needs extra hardware boards, while latter
needs some cross compiling setting. I'd like to know how do you do that?
Hi there. The notes from today's stand up call are available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-14
A copy follows.
One thing I forgot is the upcoming sprint. Please add what you'll be
working on to https://wiki.linaro.org/Internal/Events/2010-07-PlatformSprint/ToolChainWG
- it's great for networking as it helps those interested in similar
areas to track you down.
== Attendees ==
* Andrew Stubbs
* David Rusling
* Michael Hope
* Richard Earnshaw
* Ulrich Weigand
* Yao Qi
* Juilan Brown
== Minutes ==
* Andrew has been working on the release. A power failure last night
interrupted the test suite. MLH noted that Matthias has started his
own build/test process. Andrew will hold off re-running the tests
* Richard has been getting involved in the ABI discussions, which
seem to be winding down from ARM's point of view
* Ulrich has been backporting the testsuite fixes. Next task is
looking at gdb. He has run the test suite on gdb 7.2 and found more
failures than expected.
* Yao is continuing on the CSL 4.4 to 4.5 patch set. The process is
still ongoing. MLH offered to help with any Ubuntu specific packaging
problems partly due to being close in timezones.
The next stand up meeting is on Friday the 16th.
-- Michael
