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)
Hi there,
There's a recording of this mornings public plan review available on
the wiki at:
https://wiki.linaro.org/Releases/1105/PublicPlanReview
Also included is a copy of the slides and supporting documents. Might
be interesting for those who missed it.
-- Michael
A heads up. I'd like to have a brainstorming session on potential
Thumb-2 performance improvements in GCC. Think about what you'd like
in such a session, and what preperation should be done, and we can
discuss the discussion (heh) on Monday.
-- Michael
Hi there,
I noticed that there's a QEMU users forum at:
http://adt.cs.upb.de/quf/
and that the abstract submission phase is still open, and closes
November 28th. It would be great to see some participation there and
help identify other key people interested in using and improving QEMU.
--
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko
Zach Welch --
== Last Week ==
* Continued working on libunwind support. Trying to figure out why my
signal frame detection doesn't work as expected.
* Kept pace with the ltrace tree, testing recent patches on ARM.
== This Week ==
* Continue to work on libunwind signal frame detection.
Julian Brown --
== Linaro GCC ==
* Looked at issues #663198 (double-precision register expected) --
which was already fixed on the linaro branch, but the bug was reported
against a version just prior to that, and #667490 -- which involved a
possible problem with the NEON "load 0.0" patch. Experimented for a
while with the latter, but could not find anything wrong.
Followed up upstream, and requested a stand-alone test case.
* Worked on a proper solution to the VMOVN-in-big-endian-mode problem,
discovering that several other quadword-register operations were
similarly broken in the process. WIP patch sent to linaro-toolchain for
discussion, but it needs a little more work before it can be applied.
Peter Maydell --
Progress:
* qemu: more cleanup of signal handler VFP patchset;
I think I just need to add iwmmx support and it's good
* qemu: VCVT: found yet another bug, did final patchset
cleanup: submitted to upstream list [8 patch series]
* qemu: submitted a trivial patch to fix a problem where
__get_user/_put_user macros had an unnecessary local var
which could clash with a var being used by the macro user
* set up a tree on git.linaro.org which we can use for
a branch to make pull requests for ARM qemu fixes
* did a rough estimate of time to do an Eagle qemu model
(6 months + testing/bug fixing time)
Issues:
* lost some time to a problem where Linux VMs stopped being
able to talk to the LDAP server; however I have a workaround
and IT are investigating
Meetings:
* toolchain, toolchain standup, pdsw-tools, PD doughnuts
Plans
- attend Meego conference in Dublin (Nov 15-18 inc travel)
http://conference2010.meego.com/
- start on qemu consolidation by upstreaming various ARMv7
correctness fixes
Andrew Stubbs --
== GCC 4.5 ==
* Continued working on LP:663939.
* I still have not worked out how best to fix the constant
propagation problem that has been thwarting my optimization patch,
however I think I understand it better now.
* I have started on adding replicated pattern support to the
constant splitting. Initial results were good, but I discovered that I
had to rearrange the code somewhat to get the cost estimation and
negative/inverted constant support working correctly. So far, I have
it successfully using 16-bit replication pattern constants for
set/add/subtract operations. Other operations appear broken at the
moment, but it's almost certainly just a few tweaks required.
* TODO: Add support for 32-bit replicated pattern constants. Adjust
some of the other two-instruction constant generation techniques to
let them fall through to this new code, where it would be beneficial.
* Pushed the latest set of GCC patches into Linaro GCC 4.5.
Chung-Lin Tang --
== Linaro GCC ==
* Linaro #672833, one batch of my backports of Bernd's postreload
patches exposed some varargs regressions for x86-64, was reverted by
Michael. Tested the compiler and found it was fixed on mainline
rev.162384. Backporting this revision plus the postreload patches
fixed the regressions; x86-64 bootstrap also verified okay. There is
however another PR45027 fix that was needed on trunk, but needs a bit
more clarification if needed on a 4.5 compiler.
* Linaro #641397, CS issue #6753: bitfield optimization. Patch tested
without regressions, posted for CS internal review, should soon push
for Linaro merge.
* Started looking further at some GCC DF, IRA internals.
== This week ==
* Look at more Linaro issues.
* Maybe start looking at some GCC bugzilla PRs.
* There is a local ARM technical event in Hsinchu on Thursday, might
go and look around.
Yao Qi --
== Linaro GCC ==
* Mainline patch backport to Linaro 4.5.
** Patch "Fix an if statement in arm_rtx_costs_1". Verified on Linaro
4.5. 0.1% smaller on size, and 0.2% faster on speed. Merged to Linaro
4.5 by Andrew S.
** Try Nathan F's ifcvt-cond-move patch on cortex-a8 with -O2/O3. No
improvements on speed/size for EEMBC.
** Bernd's ldm/stm patch. Analyze the reason of regression on Linaro
4.5. Found something wrong in IRA rtl dump, and spend sometime on
understanding IRA rtl dump log. Thanks to Chung-Lin, I realize that IRA
dump is correct, and look back to ARM RTL patterns on ldm/stm. Compared
RTL patterns in 4.5 and 4.6, found some difference. Regenerate
ldmstm.md for Linaro 4.5 after update arm-ldmstm.ml a little bit.
Regressions goes away!
No speed improvement, but code is smaller by 0.2% in EEMBC. Still
prefer to merge to Linaro 4.5.
ocaml is an interesting language, but not easy to learn and read in vim.
* Some discussion on Linaro development process.
* My regrename improvement patch (re. LP:633243). Communicate with
Eric Botcazou back and forth, but current patch is still too
target-dependent to him, as a Middle-End maintainer. Still need some
improvements.
* Build FSF GCC trunk. CLoog requirement in configure is wrong, revert
configure to previous version, and then pass the version checking during
gcc configure.
