Hi there. The sprint is just around the corner and it's a good time
to think about how we can make best use of the week. I've put some
topics up at:
https://wiki.linaro.org/Events/2011-01-LinaroSprint/ToolChainWG
Please feel free to add to it. Have a think about anything that's
easier to do while everyone is in the same room - things like
discussions, kicking off some work, a bit of pair programming on a
problem, or anything that overlaps with another group or Ubuntu.
-- Michael
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:
* merge-correctness-fixes:
** Submitted patchset upstream to fix NaN propagation to
follow ARM ARM rules rather than x87 semantics:
http://patchwork.ozlabs.org/patch/75742/http://patchwork.ozlabs.org/patch/75743/
* maintain-beagle-models:
** Finished implementation of the OMAP NAND prefetch/postwrite
engine including its DMA support. Patches submitted to the
qemu-maemo upstream tree and merged by Juha:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/1
** Fixed the (cosmetic) bug
https://bugs.launchpad.net/qemu-maemo/+bug/622408
where we were complaining about "Unknown CMD52" when Linux probed
for the presence of SDIO cards. Fix merged into qemu-maemo:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/2
* qemu-continuous-integration:
** Discussion with Loic about setting up jobs on his Hudson
instance for testing qemu against snapshots/hwpacks.
* packageselection-arm-n-more-stable-vm-solution-for-arm
** Discussion about Ubuntu moving to using a qemu-maemo based
qemu for ARM purposes. The Ubuntu blueprint is
https://blueprints.launchpad.net/ubuntu/+spec/packageselection-arm-n-more-s…
We need to come to agreement about what parts of this are
going to be done by variously Linaro toolchain, Linaro
foundations and Ubuntu.
** I'm going through doing another rebase-and-package of
the Linaro qemu, and finishing off writing up the notes
on the process:
https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess
Meetings: toolchain, pdsw-tools, pdsw-tools xmas lunch :-)
Issues:
* a number of qemu patches in progress are logjammed behind
the outstanding git pull request
* the dbgsym debug packages for linaro kernels seem to have
vanished:
https://bugs.launchpad.net/linaro-images/+bug/691192
Absences: (complete to end of 2010)
Fri 17 Dec - Tue 4 Jan inclusive.
2011: Dallas Linaro sprint 9-15 Jan. Holiday 22 Apr - 2 May.
Hi,
* I've spent some time for testing the patches that allow the GCC trunk
to bootstrap again on ARM and posted the results to gcc-testresults
* finally tested and posted the patch that optimizes the __sync_*
builtins (#681138) on gcc-patches
* investigated on the state of the crash utility on ARM (or rather its
prerequisites like kexec)
https://wiki.linaro.org/KenWerner/Sandbox/crash-utility
* I'm on holiday now :)
Regards
Ken
Hi,
On Wed, Dec 15, 2010 at 1:44 AM, Michael Hope <michael.hope(a)linaro.org> wrote:
> On Wed, Dec 15, 2010 at 1:05 PM, Steve Langasek
> <steve.langasek(a)linaro.org> wrote:
>> Hi Michael,
>>
>> On Wed, Dec 15, 2010 at 09:29:38AM +1300, Michael Hope wrote:
>>> Hi Steve. I'd like to hand the rest of this over to you if that's OK.
>>
>> Yep, we can take it from here. To be clear, is this an additional change
>> above and beyond what Matthias reports is currently in Ubuntu gcc
>> (http://lists.linaro.org/pipermail/linaro-toolchain/2010-November/000441.html),
>> and if so, in what version of Linaro GCC is it going to become effective?
>> Do we have documentation of what the relevant failure modes caused by this
>> change *look* like, so that we can at least be triaging them appropriately
>> until there's some documentation on how to fix the resulting bugs?
>
> There will be many failures in many packages. The problem is when you
> use conditional suffixes on instructions: previously the compiler
> would insert an implicit instruction before that; now we have to be
> explicit.
>
> The failures are easy to diagnose and fix. The build will fail with a
> message from the assembler along the lines of 'xxx instruction outside
> an IT block'. The fix is to find the inline assembly code, insert the
> appropriate IT instruction, and re-build. The assembler will validate
> the IT instruction against the following conditional instructions so
> the change is quite safe.
Did someone manage to find out which versions of binutils can silently
accept the IT instructions when assembling for ARM?
This affects what advice we should give on how to avoid breaking
upstream with our additions. The safest approach is #ifdefs, but it
will be better for maintenance if we can avoid this, since it will
render the code very messy.
Cheers
---Dave
Hi there. Some of the tr-* blueprints had work items in them and this
was interfering with the tools that the PM guys use. I've created new
engineering blueprints, pulled the work items across into them, and
added the new engineering blueprint as a dependency of the old TR.
Sorry for the blueprint spam. In most cases the new blueprint has the
same name and subject as the TR one, such as the TR:
https://blueprints.launchpad.net/linaro/+spec/tr-toolchain-4.5-in-distros
which is backed by the engineering blueprint:
https://blueprints.launchpad.net/gcc-linaro/+spec/4.5-in-distros
-- Michael
Hi Richard,
Recapping on this earlier conversation:
http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000030.htmlhttp://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000035.html
Is it worth another attempt to make a case to upstream for supporting
passing -mimplicit-it=thumb by default to gas?
According to my understanding of this issue, my argument would go as follows:
* gcc currently estimates the size of asm blocks, rather than
determining the size accurately.
* gcc cannot guarantee the right answer for asm block size when asm
blocks contain directives etc., however use of directives in asm
blocks is widespread
* gcc cannot guarantee the right answer for asm block size in
Thumb-2. gcc conservatively overestimates the size by assuming that
each statement of the asm block expands to 4 bytes.
* All of Ubuntu lucid and maverick has been built with
-mimplicit-it=thumb passwd by default, with no known build or runtime
failures arising from this (so size issues aside, we have confidence
that the resulting code generation is sound)
* -mimplicit-it=thumb -mthumb makes the asm block size estimation
unsafe: the asm block can exceed the estimated size even in the
absence of directives, which may lead to fixup range errors during
assembly.
* Following the principles already established for Thumb-2 in
general the estimation can be made safe (or, as safe as the
established Thumb-2 behaviour) by raising the assumed maximum
statement expansion size for asm blocks to 6 bytes, since
-mimplicit-it will add as most a single (16-bit) IT instruction to
each statement.
* The vast majority of all asm blocks are small (< 20 instructions,
say), so the overall overestimate in sizes will generally be modest
for any given compilation unit.
* -mimplicit-it is already _required_ by the Linux kernel and
possible other projects.
...so...
* With -mimplicit-it=thumb and a 6-byte asm block statement
expansion size estimate, we have toolchain behaviour which is as
reliable, and as correct, as it is in upstream at present.
* Layout of data in the compiler output will be more optimal in some
cases, and less optimal in other cases, compared with the the current
Thumb-2 behaviour, due to differing asm block size estimates. The
exact behaviour will depend on the distribution of conditional
instructions within asm blocks.
* Taken over a whole compilation unit, the total code size
overestimate (and therefore the impact on object layout) will normally
be modest, due to the small typical size of asm blocks.
* Behaviour for -marm will not be impacted at all.
If gcc currently estimated asm block code size accurately, then I
could understand upstream's objection; but as it stands it seems to me
we wouldn't be making anything worse in practice with the proposed
change; and there is no compatibility impact (other than positive
impact).
Of course, I may have some wrong assumptions here, or there may be
some background I'm not aware of...
Comments?
Cheers
---Dave
== Linaro GCC ==
* Finish testing for big-endian/quad-word patch on mainline, and
send upstream. Not yet reviewed by an ARM maintainer, but Joseph
suggested tweaking DejaGnu's target-supports to better reflect the new
capabilities of the vectorizer in big-endian mode. I've not looked into
that yet.
* Started looking at improving element/structure load/store intrinsics.
Made it so that the structs used for loads/stores are created in the
backend so that the types can be used directly by the builtins, but
discovered that the front-end/middle-end would not play along with that
plan as they are. Thought about ways to fix that.
* Some time spent on other CodeSourcery stuff.
The Linaro Toolchain Working Group is pleased to announce the release
of both Linaro GCC 4.4 and Linaro GCC 4.5.
Linaro GCC 4.5 is the fifth release in the 4.5 series. Based off the
latest GCC 4.5.1+svn167157, it includes many ARM-focused performance
improvements and bug fixes.
Linaro GCC 4.4 is the fifth release in the 4.4 series. Based off the
latest GCC 4.4.5, it is a maintenance release that fixes one problem
found through use.
Interesting changes include:
* A new performance focused extension elimination pass
* Speed and size improvements when loading constants
* Performance improvements on compound conditionals
* A range of correctness improvements
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.5-2010.12-0
and
https://launchpad.net/gcc-linaro/+milestone/4.4-2010.12-0
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
No changes have been committed to Linaro GDB 7.2 this month.
-- Michael
* Linaro GCC 4.4/4.5
Merged the latest CS patches and Linaro merge requests into Linaro GCC
(4.4 and 4.5). Ran regression tests. Yao's patch failed so I backed it
out, and made the release tarballs. Uploaded the releases to Michael
Hope for release.
lp:686381: luatex fails to build with gcc-4.5
Fired off a test build to reproduce the problem. Will come back to this
next week.
* GCC 4.6/4.7
Posted my various queued patches up to gcc-patches(a)gcc.gnu.org for review.
Looked at the state of the GCC 4.6 upstream build. There are currently
two problems:
1. libquadmath must be disabled in a cross-build for the bootstrap phases.
2. libstdc++ doesn't build. There is a patch for it on the mail list,
but it's not applied yet.
Once gcc 4.6 builds cleanly, I shall update the Launchpad 4.6 branch,
and declare that the baseline for our development. We'll then have
somewhere to commit and track patches awaiting GCC stage 1 development.
* Other
Caught up with email following my holiday.
Yet again, my IGEPv2 board suffered a corrupt file system. I've now
upgraded the kernel and configured it to use an NFS root. The board is
now somewhat less mobile, but should work more reliably.
Continued organizing the a brain-storming session for GCC optimization
improvements.
Organised flights and hotel for both the Linaro Sprint and CodeSourcery
annual meeting in January.
== Last Week ==
* Spent time tracking down a couple of regressions that appeared in the
new ltrace release-candidate tree. Submitted a bunch of patches to fix
the issues that were discovered during that process; most have been applied.
* Finished writing fairly generic code for handling ARM-specific unwind
tables, from lookup through decoding and dispatch. It uses a few
definitions specific to libunwind, but those probably could be
eliminated with more work.
== This Week ==
* Integrate new ARM-specific bits into libunwind framework.
* Rewrite part of a portability patch for ltrace and hope that those
changes reflect the very last effort that will be required for that
particular task.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
