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
