Re my recent email "Upstream GCC feature freeze", I think we're agreed
that we need to create a branch that tracks GCC 4.6 development, but has
our own performance improvements included. The question is where to host it?
Option 1: Launchpad/bzr
Pros:
* We need no permission to do it
* The branch will naturally evolve into our 4.6 release series in time.
* The 3-way merge works well (if slowly)
* We can include patches that we have no intention of posting upstream
ever
* Our patch tracker will Just Work.
* Merge requests will be available.
Cons:
* Bzr ;)
* It's hidden away from the view of most GCC developers
Option 2: GCC SVN branch
Pros:
* We can work in the open, submitting patches via gcc-patches, as usual
* The final merge to GCC trunk (come stage 1) will be eased, a little
Cons:
* We can't really apply anything we want just for ourselves
* we may end up maintaining an LP branch shadowing the svn branch
* When we do want to do 4.6 in LP, we'll have to backport all our
patches from 4.7, and this may no longer be straightforward.
* Write permissions not clear.
* Although I think you can just go ahead and do it?
OK, so I'm sure I've missed some big ones. Please discuss! ;)
I think the big question here is, when will we start wanting to make
(unstable/experimental) Linaro GCC 4.6 releases? If we want to do it
early, then we'll have no choice but to have an LP branch to release from.
Andrew
Like everyone from Toolchain WG I will share my activites in last week:
1. cross compilers for archive
- discussed with doko about dropping update-alternatives use
- wrote gcc-defaults-armel-cross 1.4 which does proper symlinks for cross
compilers
- wrote gcc-4.5-armel-cross 1.41 which removes update-alternatives support
- wrote gcc-4.4-armel-cross 1.37 which removes update-alternatives support
- wrote armel-cross-toolchain-base 1.53 which has all updates which I had
- sent all of them to Steve for review
Status of changes:
- default version of armel cross compiler will be 4.5 like it is in Natty
- both 4.4 and 4.5 will be provided as it is for native
- any traces of update-alternatives use should be removed
Needs to be done:
- adding conflicts on older cross compilers to gcc-defaults-armel-cross
Order of upload to archive:
- armel-cross-toolchain-base
- gcc-4.5-armel-cross
- gcc-4.4-armel-cross
- gcc-defaults-armel-cross
2. Checked few old bugs do they still apply:
- Bugs #646729, #637454, #671455 are done with armel-cross-toolchain-base 1.52
(landed in maverick-proposed)
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Short week.
Finally got external hard drive for my beagle - makes it sanely possible to
natively build things.
Got eglibc cross built (Thanks to Wookey for pointing me in the right
direction with the magic incantation of dpkg-buildpackage -aarmel
--target=binary) and
easily rebuilding . I have a version with the neon version of my memset
built into it - it doesn't seem to make a noticeable difference to my
ghostscript benchmark
though.
Panda's aren't likely to turn up until mid December; arranging borrowing
an A9 is turning out to be difficult, but it looks like we should be able to
get access to
the one in the London datacentre - although it has a disc problem at the
moment.
I did manage to get a colleague to try my tests on his own Toshiba AC-10
(Tegra-2 - no Neon); the
graphs had approximately the same shape as my previous Panda tests. Memchr
looked pretty
good on there.
Also trying to look at the sign off I need for various libc access.
Dave
I mainly worked on the atomic memory operations blueprint/item:
* posted an updated patch for #643171 on the libc-ports ml after running the
glibc testsuite natively on the vexpress
* continued to learn about the ARM instructions involved :)
* started to write some gcc testcases that scan the asm output of the __sync
builtins (mainly to detect differences between the gcc versions - not sure how
useful those tests would be for upstream as the sequences may easily change)
Ken
RAG:
Red:
Amber:
Green:
Milestones:
| Planned | Estimate | Actual |
finish virtio-system | 2010-08-27 | postponed | |
get valgrind into linaro PPA | 2010-09-15 | 2010-09-28 | 2010-09-28 |
complete a qemu-maemo update | 2010-09-24 | 2010-09-22 | 2010-09-22 |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
Progress:
* Most of this week spent at the Meego conference in Dublin.
This seemed to be a rather apps-developer centric conf,
with not much of interest on the low-level side. There were
a few useful talks/conversations, though.
* Intel were giving away Atom-based netbooks to all attendees;
that's a lot of developers who are going to be testing and
optimising their apps for Atom devices rather than ARM...
* qemu: looked at https://bugs.launchpad.net/bugs/668799 ;
we don't seem to be taking the right lock before we manipulate
the graph of translation blocks. I have a fix which stops the
reported segfault, but the code has a number of "XXX not thread
safe" and "FIXME: not SMP safe" comments and generally doesn't
seem to have a coherent locking design :-(
* qemu: sent some minor patches upstream:
+ enable iwmmxt coprocessors in user mode
+ remove some unused functions from target-arm and target-sparc
+ fix a failure to build bug in a makefile
* qemu: some review of a patch to fix semihosting SYS_GET_CMDLINE
Plans
- qemu consolidation
- post-toolchain-review, sort out some milestones for
this report
Absences: (complete to end of 2010)
Thu/Fri 25-26 Nov; Fri 17 Dec - Tue 4 Jan inclusive.
(Dallas Linaro sprint 9-15 Jan.)
== This week ==
Started looking at STT_GNU_IFUNC support in BFD. There were a couple
of janitorial changes I needed to make in order to prepare elf32-arm.c
for the main patch. I tested those separately and submitted them upstream:
http://sourceware.org/ml/binutils/2010-11/msg00330.htmlhttp://sourceware.org/ml/binutils/2010-11/msg00331.html
I've now finished a prototype implementation of the STT_GNU_IFUNC
support itself. It wasn't as mechanical as I'd originally assumed,
which was nice.
Tests that I've run by hand seem to be doing the right thing.
I've now started writing tests for the testsuite (meaning:
I've completed 1 test so far).
== Next week ==
* Add more tests, including Thumb coverage.
* Start on the libc changes.
Richard
Doing an allmodconfig build on the kernel, I get the following:
CC arch/arm/kernel/asm-offsets.s
In file included from
/home/rob/proj/git/linux-2.6-dt/include/linux/kernel.h:12,
from
/home/rob/proj/git/linux-2.6-dt/include/linux/sched.h:54,
from
/home/rob/proj/git/linux-2.6-dt/arch/arm/kernel/asm-offsets.c:13:
/usr/lib/gcc/arm-linux-gnueabi/4.4.5/include/stdarg.h:40: internal
compiler error: Segmentation fault
It occurs on Maverick 4.4, 4.5 and CodeSourcery 2009Q1 cross toolchains.
It's confirmed by Codesourcery here:
http://www.codesourcery.com/archives/arm-gnu/msg03719.html
What's the status on this issue? I didn't see anything in Linaro gcc
bugs that looks related.
Rob
The STT_GNU_IFUNC blueprint:
https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/Binutils-STT_GNU_IFUNC
says "the ARM EABI will be updated to support STT_GNU_IFUNC's requirements".
I suppose the most obvious thing that needs to be defined is the relocation
number for R_ARM_IRELATIVE. What's the best way of handling that?
The main options seem to be:
1. Reserve a relocation number with ARM first (129?).
2. Go ahead and implement it without having the EABI updated.
See whether the results are good before deciding whether
to bless it in the EABI.
3. Since STT_GNU_IFUNC is a GNU-specific, treat R_ARM_IRELATIVE
as GNU-specific too, and pinch one of the R_ARM_PRIVATE relocs.
I'm pretty sure (3)'s not the way to go, but I was aiming for
completeness. :-)
Richard
Hi,
On 17 November 2010 05:35, Michael Hope <michael.hope(a)linaro.org> wrote:
> 1. How easy is it to frequently merge in SVN? It used to be terrible
> as you had to manually track the merges. These days can you do a 'svn
> merge trunk' and have it just work?
I asked Mike Meissner to answer this question. Mike is very experienced in
GCC and GCC SVN branch management. I am attaching his reply.
Ira
I sent this recently to ppc64-toolchain(a)linux.ibm.com on how to use
svnmerge to manage branches:
This script (also ~meissner/meissner/bin.sh/svnmerge) is what I use to
update svn directories, such as ibm-gcc-4_5-branch. I think I originally
got it
from Ben E. and it may be in the contrib directory.
Typically the way I start a branch, such as my normal power7-meissner
branch, I do the following:
$ export TRUNK="svn+ssh://@gcc.gnu.org/svn/gcc/trunk"
$ export BNAME="power7-meissner"
$ export BRANCH="svn+ssh://@gcc.gnu.org/svn/gcc/branches/ibm/$BNAME"
$ export SRC="$HOME/fsf-src"
$ svn delete -m"delete old branch" $BRANCH
$ svn copy -m"Clone new branch" $TRUNK $BRANCH
$ cd $SRC
$ svn co $BRANCH
$ cd $BNAME
$ svnmerge init
$ svn update # this is sometimes needed
$ svn commit -m'Create svnmerge init info'
$ export REV="xxxx" # substitute subversion id for xxxxx
$ echo "power7-meissner branch, based on $REV." > gcc/REVISION
$ touch gcc/ChangeLog.power7
$ <edit gcc/ChangeLog.power to create initial contents>
$ svn add gcc/ChangeLog.power gcc/REVISION
$ svn commit -m'Add REVISION to branch'
In particular, creating GCC/REVISION allows you to tell what subversion
revision the source is based against. You can find the information via:
$ svn propget svnmerge-integrated
but it is a lot easier if you have a compiler tree to do gcc -v. After you
do a propget, you will need to do a svn update.
In this case, I use gcc/ChangeLog.power7 to hold the ChangeLog entries
local to the branch. That way I can see a summary of the changes, but not
pollute
the normal ChangeLog files.
To do merges, you need to make sure that all local changes are checked into
the branch. Then do:
$ cd $SRC/$BNAME
$ svnmerge merge
$ <edit gcc/REVISION and ChangeLog.power7 to indicate merge>
$ <test merged files, if satisified, check them in>
$ export REV="xxxx" # substitute subversion id for xxxxx
$ svn update # just in case
$ svn commit -m"Update to subversion id $REV"
Now, to create a patch file do, make sure the files are checked in:
$ cd $SRC/$BNAME
$ export PATCHFILE="$HOME/patches/mypatch.patch01"
$ <make ChangeLog entries in $PATCHFILE>
$ svn diff --old $TRUNK --new . -r $REV >> $PATCHFILE
$ <delete ChangeLog.power7, REVISION, property changes from $PATCHFILE>
$ submit patch
To see if there are changes to be merge in:
$ svnmerge avail
For example on the ibm-gcc-4_5-branch, the following changes are available
to be merged in: 164657-166510 when I originally wrote this message on the
9th
of November, and Peter has subsequently updated the merge.
I put the folliwng in ~/.subversion/config to provide my own diff command:
### Set diff-cmd to the absolute path of your 'diff' program.
### This will override the compile-time default, which is to use
### Subversion's internal diff implementation.
diff-cmd = /home/meissner/bin.sh/svndiff
Every so often, I find svnmerge misses, for example in deleting
directories.
It is helpful to do a diff from the mainline every so often to make sure
you are not missing newly created files or still are keeping older files or
just missed a change.
I'll include svndiff for the smarter svndiff command and mrm-changelog.el
that looks for the ChangeLog.<name> files I use in different branches. Feel
free to contact me to clarify some stuff.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner(a)linux.vnet.ibm.com fax +1 (978) 399-6899
(See attached file: svnmerge)(See attached file: svndiff)(See attached
file: mrm-changelog.el)
