The Linaro Toolchain Working Group is pleased to announce
the availability of a "developer preview" of Valgrind
which includes the support for ARM and Thumb which has
recently been added by the Valgrind developers.
Our aim with this preview release is to advertise
Valgrind's improved ARM support and encourage people
to try it out and find bugs before the official 3.6.0
release. Please report bugs via upstream's BTS:
http://valgrind.org/support/bug_reports.html
or you can ask on linaro-toolchain(a)lists.linaro.org
if you have any problems.
This release is a snapshot of upstream subversion; it
should generally work but you may encounter bugs, especially
if you run it on hand-optimised assembly that uses obscure
instructions.
New (upstream) features in this snapshot include:
* Greatly improved support for ARM
* Support for the Thumb instruction set
* Support for NEON and VFPv3 instructions
Known issues:
* callgrind has difficulty identifying ARM function
call and return so may not produce useful results
Downloads are available from the Linaro Overlay PPA:
https://launchpad.net/~linaro-maintainers/+archive/overlay
...so if you're running Linaro on an ARM system you
should be able to just install it with
'apt-get install valgrind'.
-- Peter Maydell
To All Ye Linaro Toolchain Folk, (and OpenOCD developers too)
After a week of reading specifications and code, I am ready to start
doing some serious hacking on OpenOCD. The following outlines my present
plans and expectations, with the caveat that time can change everything.
Last week, I started testing my BeagleBoard with OpenOCD, so I have
begun trying to validate and improve the Cortex-A8 support. Indeed, I
have already committed a minor patch that fixed a bug in the trunk
caused by new command syntax required to distinguish physical memory
addresses from virtual ones. That bug had been preventing the BeagleBoard
support from working for several months, so this seems to show that
nobody has been using (or even testing) the latest code with that board.
It seems that much of the debug architecture can be shared between these
two cores, so features added and bugs fixed for A8 should help me
implement A9 faster. Indeed, A9 support may be more a matter of
refactoring the existing code than developing new code. In this respect,
the lists of tasks for A8 and A9 may end up proceeding in parallel.
Cortex-A8:
1) Add missing topology detection for determining location of AHB-AP
(for system memory access), APB-AP (for DAP and other CoreSight
components), and register address range for accessing the DAP.
2) Fix Halt After Reset functionality (using vector catch magic).
3) Expose missing VFP3/NEON registers (only when present).
4) Fix various memory and resource leaks.
Cortex-A9:
1) Basic bring-up to successful attachment with debugger.
2) Develop board scripts for common evaluation boards.
3) Work on advanced features:
- download and run algorithms out of memory,
- breakpoints/watchpoints,
- tracing and performance monitoring,
4) Ensure SMP support works out-of-the-box.
Finally, it would be good to produce a new release when all of these
changes have made it into the tree. Due to various factors, the project
has not achieved a regular release schedule, but these features would
help to justify the effort from the community.
P.S. I have cc'd the openocd-development list in the hope of generating
useful feedback, but it requires subscribing to post (last I checked).
Sorry for the bad netiquette.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
Hello,
I've now checked the Linaro branding changes in to the gdb-linaro Bazaar
repository.
I've created a Wiki page describing the Linaro GDB release process based on
that repository:
http://wiki.linaro.org/WorkingGroups/ToolChain/GDBReleaseProcess
(modeled after Andrew's GCCReleaseProcess page)
Review and comments are welcome!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi,
In case this is useful in its current (unfinished!) form: here are some
notes I made whilst looking at a couple of the items listed for CS308
here:
https://wiki.linaro.org/Internal/Contractors/CodeSourcery
Namely:
* automatic vector size selection (it's currently selected by command
line switch)
* also consider ARMv6 SIMD vectors (see CS309)
* mixed size vectors (using to most appropriate size in each case)
* ensure that all gcc vectorizer pattern names are implemented in the
machine description (those that can be).
I've not even started on looking at:
* loops with more than two basic blocks (caused by if statements
(anything else?))
* use of specialized load instructions
* Conversly, perhaps identify NEON capabilities not covered by GCC
patterns, and add them to gcc (e.g. vld2/vld3/vld4 insns)
* any other missed opportunities (identify common idioms and teach the
compiler to deal with them)
I'm not likely to have time to restart work on the vectorization study
for at least a couple of days, because of other CodeSourcery work. But
perhaps the attached will still be useful in the meantime.
Do you (Ira) have access to the ARM ISA docs detailing the NEON
instructions?
Cheers,
Julian
While trying out the u-boot-next branch I found a problem. First some
explanation. On most platforms, u-boot is linked to the address it
will first start running. For example when using NOR flash U-Boot
will be linked to an address in flash. Very early in the boot
process, U-Boot copies itself to the top and ram and jumps there.
This relocation has worked for years on powerpc and other arches. The
-next tree adds this for arm and it almost works.
The part that does not work is that some veneer routines do not get fixed up.
Here is an example. A routine called i2c_init calls __aeabi_idiv.
Here is the disassembly:
...
288: e59f0148 ldr r0, [pc, #328] ; 3d8 <i2c_init+0x1a4>
28c: e1a01083 lsl r1, r3, #1
290: ebfffffe bl 0 <__aeabi_idiv>
294: e2507006 subs r7, r0, #6
298: 4a000001 bmi 2a4 <i2c_init+0x70>
Later after this .o is linked with everything else and libgcc that morphs to:
8000b384: e59f0148 ldr r0, [pc, #328] ; 8000b4d4
<_end+0xfff97c98>
8000b388: e1a01083 lsl r1, r3, #1
8000b38c: eb00aa43 bl 80035ca0 <____aeabi_idiv_veneer>
8000b390: e2507006 subs r7, r0, #6
8000b394: 4a000001 bmi 8000b3a0 <i2c_init+0x70>
and the veneer version is at the end of text with other veneers:
80035ca0 <____aeabi_idiv_veneer>:
80035ca0: e51ff004 ldr pc, [pc, #-4] ; 80035ca4
<_end+0xfffc2468>
80035ca4: 80035999 .word 0x80035999
80035ca8 <____aeabi_llsl_veneer>:
80035ca8: e51ff004 ldr pc, [pc, #-4] ; 80035cac
<_end+0xfffc2470>
80035cac: 80035c7d .word 0x80035c7d
80035cb0 <____aeabi_lasr_veneer>:
80035cb0: e51ff004 ldr pc, [pc, #-4] ; 80035cb4
<_end+0xfffc2478>
80035cb4: 80035c61 .word 0x80035c61
80035cb8 <____aeabi_llsr_veneer>:
80035cb8: e51ff004 ldr pc, [pc, #-4] ; 80035cbc
<_end+0xfffc2480>
80035cbc: 80035c49 .word 0x80035c49
80035cc0 <____aeabi_uidivmod_veneer>:
80035cc0: e51ff004 ldr pc, [pc, #-4] ; 80035cc4
<_end+0xfffc2488>
80035cc4: 8003597d .word 0x8003597d
80035cc8 <____aeabi_uidiv_veneer>:
80035cc8: e51ff004 ldr pc, [pc, #-4] ; 80035ccc
<_end+0xfffc2490>
80035ccc: 80035721 .word 0x80035721
80035cd0 <____aeabi_idivmod_veneer>:
80035cd0: e51ff004 ldr pc, [pc, #-4] ; 80035cd4
<_end+0xfffc2498>
80035cd4: 80035c2d .word 0x80035c2d
then if we look at 80035998 we see some thumb code.
80035998 <__aeabi_idiv>:
80035998: 2900 cmp r1, #0
8003599a: f000 813e beq.w 80035c1a <.divsi3_nodiv0+0x27c>
When u-boot copies itself to ram it relocates the jump tables it knows
about and could relocate the addresses in the veneer routines if it
knew about them.
There are at least three possible ways to fix these:
1) u-boot has its own private libgcc and if I use it the problem goes away.
2) is there an option for the toolchain to use an arm libgcc instead of thumb?
3) is there a way to find the veneers at runtime and fix them up?
All input welcome.
Thanks,
John
Hello Michael,
I'm looking into "branding" changes needed for a Linaro GDB release. So
far I've made the following changes:
- Set default PKGVERSION to "Linaro GDB" instead of "GDB"
- Set default BUGURL to "http://bugs.launchpad.net/gdb-linaro/" instead of
"http://www.gnu.org/software/gdb/bugs/"
- Set version number according to Linaro version scheme
- Update release script to generate tarballs/directories named
"gdb-linaro-$VERSION" instead of "gdb-$VERSION".
As a result, the default GDB startup output now reads:
GNU gdb (Linaro GDB) 7.2-2010.10-0
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
Do you agree that this is the way we should go? Have I overlooked
anything?
Unless there are objections, I'm planning to check these changes in later
this week.
As a related question, the generated files in a standard GDB 7.2 release
seem to have been built on a relatively old system (RHEL 4 ?), which is
visible through the versions of tools like bison, flex, texinfo, and
gettext used to build those files. When building our Linaro GDB release
tarballs, should we:
- just use the tools as installed on a recent build system (say, Ubuntu
Lucid), or
- attempt to rebuild the release with the exact same set of tools used for
the GDB 7.2 release?
The second option has the advantage of reducing the amount of changes, e.g.
visible in a full diff of the release tarballs. However, it has the
disadvantage that reconstructing those exact set of tools (including Red
Hat patches, it seems) is somewhat difficult, and can in addition lead to
somewhat outdated results ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi all,
I was recently hired by CodeSourcery and have been assigned to Linaro
for the purpose of improving OpenOCD.
Specifically, I will be adding new support for Cortex-A9 SMP, though I
may also make a few improvements to its handling of Cortex-A8 in the
process. If you have experience using OpenOCD in these contexts, let me
know if you have any specific requests for features or fixes, and I will
try to fold them into my plans.
After this cross-posted introduction, I believe that most of my
correspondence will appear on the Toolchain mailing list, but I wanted
to make sure that everyone knows that they can find me there.
Cheers,
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
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.4 is the third release in the 4.4 series. Based off the
latest GCC 4.4.4, it pulls in the pre-4.4.5 changes made by the FSF
over the last six months.
Linaro GCC 4.5 is the second release in the 4.5 series. Based off the
latest GCC 4.5.1, it finishes the merge of many ARM-focused
performance improvements and bug fixes.
Interesting changes include:
* Improved performance on the Cortex-A9
* Backports of a range of performance improvements from mainline
* New inline versions of the GCC builtin sync primitives
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
Also available is an early release of optimised string routines for
the Cortex-A series, including a mix of NEON and Thumb-2 versions of
memcpy(), memset(), strcpy(), strcmp(), and strlen(). For more
information see:
https://launchpad.net/cortex-strings
Pre-build packages are available in the Linaro Toolchain PPA at:
https://launchpad.net/~linaro-toolchain-dev/+archive/ppa
-- Michael
Hi,
We are looking for some possible improvements and optimizations on
thumb2 code size. Currently, I am running some benchmarks with
compilation flag "-Os -march=armv7-a -mthumb", and hope to find some
thing interesting that we can improve. Beside that, do you have some
ideas on this topic? or do you have some observations on thumb2 code
that we may probably improve the size?
Any thoughts on this are appreciated.
Yao
I think that it is easier to describe situation in email then on irc.
Currently there are 4 packages related to cross compilation support:
- armel-cross-toolchain-base (a-c-t-base in short)
- gcc-4.4-armel-cross
- gcc-4.5-armel-cross
- gcc-defaults-armel-cross
Each of them got into archive but they need to be updated to get installable
packages.
Status of each package:
1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source
4.5.1-6ubuntu1 version. This package is used to bootstrap armel cross
toolchain and generates:
- binutils-arm-linux-gnueabi (from binutils-source)
- libc6(-dev,-dbg)-armel-cross (from eglibc-source)
- linux-libc-dev-armel-cross (from linux-source-2.6.35)
- gcc-4.5-arm-linux-gnueabi-base, libgcc1(-dbg)-armel-cross (from
gcc-4.5-source)
libgcc1* packages have /usr/share/doc/ directories as symlinks to
/usr/share/doc/gcc-4.5-arm-linux-gnueabi-base/
I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base
package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have
/usr/share/doc/ directories pointing into gcc-4.5-base one. Need to fix
this symlink by providing those files in libgcc1 package instead.
2. gcc-4.4-armel-cross is at 1.36 in archive and was built with gcc-4.4-source
4.4.4-14ubuntu4 version. This package provides compilers,
libstc++6-4.4-(dev,dbg,pic)-armel-cross, libmudflap0-4.4-dev-armel-cross
and gcc-4.4-arm-linux-gnueabi-base packages.
I have 1.38 version ready to upload which fixes #637454 #640298 bugs.
3. gcc-4.5-armel-cross is at 1.35 in archive and was built with gcc-4.5-source
4.5.1-7ubuntu1 version. This package provides compilers and runtime
libraries. But it does not provide libgcc1(-dbg)-armel-cross and
gcc-4.5-arm-linux-gnueabi-base because they are in a-c-t-base source
package. All resulting packages have /usr/share/doc/ directories pointing
into gcc-4.5-arm-linux-gnueabi-base one which is policy violation.
I have 1.37 version ready to upload which fixes #637454 #640298 bugs and
provides gcc-4.5-arm-linux-gnueabi-base package so policy violation is
removed.
4. gcc-defaults-armel-cross is at 1.3 in archive and does not require any
changes.
Main problem is that packages generated from gcc-4.5-source are split into two
packages: armel-cross-toolchain-base (libgcc1(-dbg)-armel-cross) and
gcc-4.5-armel-cross (all the rest). This was required to allow to bootstrap
cross compiler but gives problems when one is built with other version of
gcc-4.5-source then other - resulting packages are not installable (we have it
now in archive). It is also a thing which Matthias does not like and I
understand it. For now my only solution is to build both with one version of
gcc-4.5-source.
What are your opinions?
http://marcin.juszkiewicz.com.pl/download/ubuntu/ is download link for
mentioned versions.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
xf. http://lists.linaro.org/pipermail/linaro-toolchain/2010-August/000069.html
> It is not upstreamable due to copyright issues, but we have a policy
> that we can keep such patches, if we wish.
I wrote this patch. If I am the copyright issue, then there is no issue.
I have a copyright assignment for all my GCC work to the FSF. That
assignment also covers the patch in the e-mail stored at
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html. I consider
copyright to all my patches assigned to the FSF if I have submitted
the patches to gcc-patches(a)gcc.gnu.org, or attached them to a Problem
Report in GCC bugzilla, or both.
The only reason why this patch for GIMPLE PRE is not in the FSF GCC
already, is that I just never cared enough to pursue it. GCC is just a
hobby for me, and experimenting with ideas is fun. Doing all the
required testing for inclusion in the FSF GCC is not fun and it costs
time that I usually can't find. I am just too busy with other things
to clear off this and other pending patches/ideas from my TODO list
:-)
If you wish to submit this patch for the FSF GCC, please feel free to
do so. In fact, I'd encourage you to do so. Likewise for my patch for
e.g. http://gcc.gnu.org/PR20070, and for the GIMPLE hoisting pass.
Ciao!
Steven
Hi,
about the status of binutils testsuite Thumb coverage (CS204 in the
workplan), I have filed two Launchpad bugs:
#640263: Testsuite coverage: Thumb-2 VFP/NEON encodings
https://bugs.launchpad.net/binutils-linaro/+bug/640263
#640272: Testsuite coverage: Thumb relocations
https://bugs.launchpad.net/binutils-linaro/+bug/640272
To summarize: I currently do not see any testing of Thumb-2 VFP/NEON
encodings; Thumb mode relocations are also only barely tested in the ld
testsuite.
Also, please inform if there are any other areas of binutils Thumb
testing that may be of concern to Linaro.
Thanks,
Chung-Lin
* Goal
Goal of this work is to look for thumb2 code size improvements on FSF
GCC trunk.
* Methodology
** Build FSF GCC trunk w/ and wo/ hardfp, run benchmarks including
eembc, spec2000, and dhrystone, and check asm code to see if there is
any possible improvements on size.
** Get input and suggestion from ARM experts.
** Search open PRs in GCC bugzilla.
* Results
Each item has been tracked on launchpad, and is listed with some elements,
** Cause: cause of this problem is known or unknown
** Difficulty: estimation of implementation difficulty
** Recommendation: Yao's recommendation on that bug for next step
1. LP:633233 Push/pop low register rather than high register when
keeping stack alignment
As Richard E. pointed out, it was implemented in gcc-4.5 on 2009, but
Yao still can see the usage of r8 on FSF GCC trunk.
Cause: Might be a regression if problem disappears on gcc-4.5.
Difficulty: Easy. might not hard to fix a regression.
Recommendations: Fix this regression if it is.
2. LP:633243 Improve regrename to make use of low registers.
Get input from Bernd S. and Julian B. Initial implementation has been
suggested by Bernd S.
Cause: current regrename in gcc treats high and low registers equally.
Difficulty: Medium.
Recommendation: Implement it as Bernd suggested, and do benchmarking
to see how much size is improved.
3. LP:634682 Redundant uxth/sxth insn are generated
Cause: Unknown
Difficulty: Unknown
Recommendation: No recommendation so far.
4. LP:634696 Function is not inlined properly with -Os
In consumer/cjpeg/jmemmgr.c, GCC inlined out_of_memory() with -Os, so
increase code size.
Cause: Unknown.
Difficulty: Unknown
Recommendation: Educate GCC to inline carefully when -Os is turned on.
5. GCC PR40730 LP:634731 Redundant memory load
6. LP:634738 inefficient code to extract least bits from an integer value
GCC PR40697 is for thumb-1. The same problem is in thumb-2.
Cause: Unknown.
Difficulty: Medium.
Recommendation: Fix it the similar way as fixing GCC PR40697.
7. LP:634891 Replace load/store by memcpy more aggressively
Difficulty: Should be easy.
Recommendation: Fix to this problem might be "reduce threshold value
once -Os is turned on".
8. LP:637220 allocate local variables with fewer instructions
GCC PR40657 is about this kind of problem, and was fixed. The similar
prolbme exits on gcc with hardfp.
Cause: Unknown.
Difficulty: Unknown.
Recommendation: No recommendation so far.
9. GCC PR 43721 Failure to optimize (a/b) and (a%b) into single
__aeabi_idivmod call
Difficulty: Medium or easy.
Recommendation: No.
10. LP:637814 Combine add/move to add
LP:637882 Combine ldr/mov to ldr
Possible improvements have been found. No idea how to fix it yet.
Cause: Unknown.
Difficulty: Unknown.
Recommendation: No.
11. LP:638014 Replace memset by memclr when 2nd parameter is zero
Difficulty: Easy.
Recommendation: No recommendation so far.
12. LP:625233 Merge constant pools for small functions
Cause: Unknown.
Difficulty: Medium.
Recommendation: No.
13. LP:638935 Replace multiple vldr by vldm
Some vldr insns accessing consecutive address can be replaced by
single vldm. It is not about thumb2, but related to code size optimization.
Cause: Unknown.
Difficulty: Medium.
Recommendation: No.
--
Yao Qi
CodeSourcery
yao(a)codesourcery.com
(650) 331-3385 x739
Hi there. I've always wanted to mix this:
http://www.futurlec.com/ET-STM32_Stamp.shtml
with some of this:
http://bit.ly/cD0JPS
to control my one of these:
http://www.traxxas.com/products/electric/rustler2006/gallery/3705-3qrtr-Bla…
and it sounds like a good opportunity to dogfood the Linaro toolchain
at the same time. What's the best way to set up a Cortex-M3 toolchain
with an appropriate newlib and libgcc?
A wrapper script works fine but I need a way of recompiling libgcc for
the Cortex-M series. I'd love to get a arm-none-eabi toolchain
package out of this that others could use. Could I re-work the cross
packaging to use newlib and change the configure flags instead? Are
there existing Debianised cross packages that I could reuse?
Ta,
-- Michael
Hi Andrew. Well, the builds are done and they're OK. I've added the
ability to compare against an explicit release to make checking
regressions easier.
4.4 results are here:
http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs…http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs…http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs…
i686 and x86_64 have not regressed since 2010.08.
On arm, and ignoring the limits test, 2010.09 adds a failure on
gcc.c-torture/compile/991026-2.c. According to the log the run timed
out but I can't reproduce it.
4.5 results are here:
http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs…http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs…http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs…
i686 has not regressed since 2010.08. x86_64 fails on
gcc.target/i386/wmul-1.c, but this is a new tests for new features and
are not a regression against 4.5.1.
arm is messier. The following new failures exist:
Vectoriser related:
* g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorized 1 loops" 1
* g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
* gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect
"vectorized 1 loops" 1
* gcc.dg/vect/vect-multitypes-12.c scan-tree-dump-times vect
"vectorized 1 loops" 1
* gcc.dg/vect/vect-reduc-dot-s16b.c scan-tree-dump-times vect
"vectorized 1 loops" 0
* gcc.dg/vect/vect-reduc-pattern-1a.c scan-tree-dump-times vect
"vectorized 1 loops" 0
* gcc.dg/vect/vect-reduc-pattern-1b.c scan-tree-dump-times vect
"vectorized 1 loops" 0
* gcc.dg/vect/vect-reduc-pattern-1c.c scan-tree-dump-times vect
"vectorized 1 loops" 0
* gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect
"vectorized 1 loops" 0
* gcc.dg/vect/vect-reduc-pattern-2b.c scan-tree-dump-times vect
"vectorized 1 loops" 0
* gcc.dg/vect/wrapv-vect-reduc-pattern-2c.c scan-tree-dump-times
vect "vectorized 1 loops" 0
Others:
* gcc.target/arm/neon-load-df0.c scan-assembler vmov.i32[
\t]+[dD][0-9]+, #0\n
* gcc.target/arm/synchronize.c scan-assembler __sync_synchronize
neon-load-df0 is a new test. synchronize.c is an incorrect test as
the compiler now correctly uses the dmb instruction.
Your thoughts?
-- Michael
I would like to announce that my work on armel cross toolchain got to the very
nice point - all packages are available from PPA.
What does it mean to you?
1. no "are you sure to install those unverified packages" messages from APT
2. ability to easily rebuild toolchain on own machines
So if you used my repository from people.canonical.com then please switch to
PPA one:
add-apt-repository ppa:hrw/armel-cross-compilers
Old repository will be available for some time but will not get any updates.
Next step: merging those packages into Maverick release.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
I've been checking over the benchmarks as a lead up to the 2010.09
release. We're in a good way compared to both 4.4.4 and 4.5.1 for
most non-trivial tests.
* pybench is 10.9 % faster than 4.4.4 and 7.7 % faster than 4.5.1.
* linpack is 46.4 % faster than 4.4.4 and the same as 4.5.1.
* ffmpeg h.264 video decode (with hand written assembler versions
turned off) is 15.4 % faster than 4.4.4 and 1.2 % faster than 4.5.1.
All results are statistically invalid and against poor workloads, but
I'll work on that.
See http://ex.seabright.co.nz/helpers/benchcompare for more.
-- Michael
Loïc Minier wrote:
> I see you moved the wiki page to the public space, thanks
>
> Couple of notes:
> * make sure you use the rename action on the page, I think this will
> preserver history (I didn't check whether you did or not, but I think
> not)
No, I didn't. I use copy and paste. I'll use rename action.
> * add a page at the old location with "#redirect NewPage" or
> "#refresh 0 http://newurl/"
OK, got it. Thanks for your help on wiki.
...are available here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-09-06
A copy and activity reports are included below.
-- Michael
Attendees
• Name Email IRC Nick
Andrew Stubbs ams(a)codesourcery.com ams_cs
Chung-Lin Tang cltang(a)codesourcery.com cltang
Julian Brown julian(a)codesourcery.com jbrown
Loïc Minier lool(a)linaro.org lool
Marcin Juszkiewicz marcin.juszkiewicz(a)linaro.org hrw
Matthias Klose doko(a)canonical.com doko
Michael Hope michael.hope(a)linaro.org michaelh
Peter Maydell peter.maydell(a)linaro.org pm215
Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw
Ulrich Weigand ulrich.weigand(a)linaro.org uweigand
Yao Qi yao(a)codesourcery.com yao
Agenda
• Licensing of string routines
• State of valgrind
• State of GDB
• Open tickets
□ 600298, 616141, 604753: SMP/sync related
□ 605059 4.4.5
□ 629671 ICE in reload_cse_simplify_operands in thumb-1 mode
□ 590696 Wrong use of objdump during cross build
• Upcoming release
• Creating blueprints
Blueprint Assignee
Initial delivery of Linaro GCC 4.4 ams
Cross Compiler Packages hrw
Action Items from this Meeting
• ACTION: Richard to check with the legal department on string licensing
issues
• ACTION: Peter to talk with valgrind upstream re: Linaro releasing a
ARM-focused version
• ACTION: Michael to organise an 'experimental' PPA that toolchain output can
go into
• ACTION: Michael to talk with Cody Somerville re: building on ARM
• ACTION: Michael to set up a GDB 7.2 based off the release tarball
• ACTION: Andrew to pull sync changes back into 4.4 for this release
• ACTION: Michael to assign appropriate sync ticket to Andrew to track the
backport
• ACTION: Andrew to merge the current post 4.4.4 release branch into our 4.4
for this release
• ACTION: Julian to do a basic investigation into 629671
• ACTION: Andrew to merge the cross-compile objdump ticket into this release
and re-kick upstream process
Action Items from Previous Meeting
• ACTION: Michael to re-check with TSC that we can assign copyright but keep
ability to relicense
• DONE: Yao to continue on GDB for a week then switch to investigation
• ACTION: Peter to check into the state and progress of valgrind for the
meeting on the 30th.
• ACTION: Chung-Lin to shift the CSL backport list out onto the Linaro wiki
• ACTION: Michael to see about doing an archive rebuild with 4.5
• DONE: Michael to send IBM's list to Yao
Minutes
String routines:
• Michael asked Richard about getting the current str* routines by ARM
transferred to Linaro
• Linaro will then get these into other C libraries
• FSF prefers LGPL and copyright for glibc
• Linaro prefers MIT/X11 everywhere so that fixes and improvements can be
shared
• Richard is concerned about the copyright assignment and any patent grant
• ACTION: Richard to check with the legal department on string licensing
issues
• Extreme fallback is to re-write the routines to all be under Linaro
copyright. memcpy() and similar may need this
Valgrind:
• Peter has been looking at how it works on the ARM platform
• Upstream is very responsive to issues
• Now works on Firefox and OO.org
• Upstrem doesn't have any particular release cycle
• ARM changes are pretty extensive and can't be extracted
• Peter suggested making valgrind available in a PPA to start with
• NEON detection at startup is remaining issue
• What next?
□ Packaging is straight forward
□ Don't want to steal upstream's thunder or release something
inappropriate
□ ACTION: Peter to talk with valgrind upstream re: Linaro releasing a
ARM-focused version
• Could bring into the Linaro overlay PPA
• ACTION: Michael to organise an 'experimental' PPA that toolchain output can
go into
• ACTION: Michael to talk with Cody Somerville re: building on ARM
GDB:
• 7.2 is now available
• Time to start up a gdb-linaro based on that
• Matthias mentioned that we will have GDB 7.2 on Maverick
• How should we manage the source
□ QEMU is over git
□ Could use bzr or git
□ bzr with Launchpad can't handle multiple branches when pulling from git
□ GDB is unique in how it's mixed in with the rest of the projects hosted
on sourceare
□ Branches as such are trucky
□ Could just base off tarballs
□ ACTION: Michael to set up a GDB 7.2 based off the release tarball
Tickets:
• ACTION: Andrew to pull sync changes back into 4.4 for this release
• ACTION: Michael to assign appropriate sync ticket to Andrew to track the
backport
• ACTION: Andrew to merge the current post 4.4.4 release branch into our 4.4
for this release
• ACTION: Julian to do a basic investigation into 629671
• ACTION: Andrew to merge the cross-compile objdump ticket into this release
and re-kick upstream process
Patch tracker:
• Andrew noted that it is now fully populated with the GCC data
• Has assigned various patches that still need to go upstream to Yao and
Julian
Next meeting is on 2010-09-08 on the public code.
--- Chung-Lin Tang
== Linaro Toolchain ==
* Google ARM patch sets: committed a second set to SG++ 4.5 trunk on
Tues. AndrewS pushed both sets to Linaro. Worked on a third set, those
related to PR42235, but this time regression test results were not so
clean. Will look into, but considering whether to stop the backports
here.
* LP:628526, submitted a patch to gcc-patches for explicitly turning
off stack protection in libgcc build flags, awaiting response.
* LP:601030, eglibc 2.11/12 problem with ___longjmp_chk on x86-64.
Problem seems to be clear, fix quite simple, but so far cannot seem to
reproduce and verify. Also unclear if I should send the fix to eglibc
or glibc, the idea of the latter making me a bit nervous... :P
== libffi ==
* Got an acknowledgement from the libffi maintainer that he'll review
the VFP hard-float support patch soon.
== This week ==
* Look into remaining Google approved patches, mainly those related to
PR42235 and PR42575.
* Try to reproduce LP:601030 and send patch soon.
* Linaro GCC investigations.
--- Andrew Stubbs
== Linaro GCC ==
* Michael has get the new patch tracker into a usable state. I've
transferred all the data from the old wiki tracker, and looked up the
remaining data as far as I can. The new tracker should now be fully
populated with data. It's here, for the moment:
http://ex.seabright.co.nz/helpers/patchtrack
* Start Yao and Julian on the optimization investigation tasks.
* Continue trawl through the CS bugs looking for candidates to push
to the Linaro tracker.
== Other ==
* Public holiday on Monday.
* Attended the monthly CS/Linaro sync meeting.
--- Yao Qi
== Linaro GDB wrap up ==
* LP:615993 gdb.base/sigstep.exp failures
Patch was committed to gdb mainline and 7.2 branch.
* LP:615995 gdb.base/watch-vfork.exp failures
Discussed with Pedro, create a patch, which fixed failures on ARM,
but can't fix failures on x86(they are caused by different problems).
Leave the x86 failures there, and patch is being reviewed in
gdb-patches.
== Linaro GCC ==
* CS306:Investigate on thumb2 improvement
Read/understand previous effort related on code size
improvement from CSL wiki pages.
Experiment with CSL scripts for size benchmarking. With Dan's
help, run benchmarking in a correct/reasonable way.
'Reproduce' some inefficient code mentioned by Julian. Some of them
are still there.
== Misc ==
* LP:605042
Revert one patch, and rebuild it. No seg fault is found.
== This Week ==
* Continue my work on CS306.
--- Peter Maydell
RAG:
Red:
Amber: virtio-system writeup not going as fast as expected
Green: ARM legal OK now received
Milestones:
| Planned | Estimate | Actual |
finish virtio-system | 2010-08-27 | ? | |
I need to replan this (no forward progress this week
because more important stuff intervened)
Progress:
virtio-system:
- actually trying a SATA disk revealed that the PB926 PCI
interrupt mapping was wrong; now fixed after consulting
the schematics and a round or two of patch testing with Arnd
- I have a PB1176 board but it doesn't seem to talk to
the serial port on poweron. Will try a firmware reflash
but it might just be broken...
- no progress on writeup because other things intervened.
valgrind:
- went through the motions of getting a valgrind svn snapshot
into the ubuntu packaging
- tested on pegatron (A8, maverick, thumb2), found four bugs:
+ BX PC not implemented (fixed upstream)
https://bugs.kde.org/show_bug.cgi?id=249775
+ RBIT not implemented (fixed upstream)
https://bugs.kde.org/show_bug.cgi?id=249924
+ pwrite64 syscall not implemented (fixed upstream)
https://bugs.kde.org/show_bug.cgi?id=249996
+ test for presence of neon wrong
https://bugs.kde.org/show_bug.cgi?id=249775
With a bodge for the last and the fixes for the first 3,
valgrind now successfully runs openoffice and firefox.
other:
- Investigated https://bugs.launchpad.net/bugs/628471 : qemu-maemo
doesn't work with new linaro beagleboard kernels. It looks
like we now try to probe for NAND (which failed earlier
for other reasons which I suspect are a now-fixed bug),
and qemu-maemo's NAND implementation doesn't map anything at
the address the nand code is trying to poll for a status bit.
- first post to qemu-devel :-) (review of somebody's
patch to not confuse SMC with BKPT in the arm decoder)
Plans:
virtio-system:
- hoping to get the qemu patches into the ubuntu qemu-maemo
package, which will avoid the need to talk about patching qemu
- finish the writeup and put it on the wiki
- test PCI patches on PB1176
valgrind:
- respin a valgrind with proper fixes for everything and
put it in a PPA somewhere
other:
- come up with some fix or workaround for #628471
- put the rebased ubuntu qemu-maemo work up onto gitorious
so other people can see it
Absences:
Friday 5 November and 20 other days in this calendar year
Looks good. I've created a real project, added a README/LICENSE, and
merged your changes. See:
https://launchpad.net/tcwg-web
There was a funny render difference between Firefox and Chromium -
revisions with no bugs lead to a rowspan of zero which Firefox doesn't
like. I also pulled some common code out into a function and used the
built-in variable 'loop'. 'loop' is quite nice as it provides values
like .index, .first, .odd, and so on based on your position in the
loop.
-- Michael
On Fri, Sep 3, 2010 at 11:02 PM, Andrew Stubbs <ams(a)codesourcery.com> wrote:
> Hi Michael,
>
> I've been playing with you patch tracker, and come up with this:
>
> https://code.launchpad.net/~ams-codesourcery/+junk/tcwg-web
>
> I don't seem to be able to propose an official merge request to your branch,
> but it's just a quick implementation anyway, and could probably be cleaned
> up.
>
> The patch renders each ticket in it's own row (without changing the way the
> first two columns are rendered). This means they can have their own colour
> and we can maybe see better what status goes with what bug.
>
> To see an example of what it does, see revision 4.4:93544
>
> Andrew
>
I want to share status of my cross compiler packages work with all of you.
Some time ago I did a split of them into two:
- armel-cross-toolchain-base (1.36 now)
- armel-cross-toolchain (1.29 now)
Where first one provides binutils, linux headers, libc6 and libgcc
packages. Second provides final gcc.
Today I got a-c-t-base to a moment when it builds fine on PPA [1]. 1.36 got
sent for rebuild to fix missing gcc-4.5-arm-linux-gnueabi-base package. When
it will build then a-c-toolchain package will get uploaded for build.
Result will deprecate my current repository at people.canonical.com [2]
because PPA gives signed repository.
On Monday I will probably have to update both components because there was
gcc-4.4 upload so probably gcc-4.5 will follow (so I will be able to drop one
patch).
Additionally I made 'gcc-defaults-armel-cross' package (available in [1])
which makes installing of cross compilers a bit easier (no need to worry which
version to install - just "apt-get install gcc-arm-linux-gnueabi" is enough).
Selection of cross gcc version is done in other way then native one. Native is
using "gcc" package which contains /usr/bin/gcc as symlink to /usr/bin/gcc-4.4
file. Cross gcc uses "update-alternatives" to setup /usr/bin/arm-linux-
gnueabi-gcc file. I want to fix it in 11.04 so cross gcc will use same method
as native one.
1. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler
2. http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Michael,
a quick update to our discussion today: actually, GDB 7.2 has already been
released earlier today:
http://sourceware.org/ml/gdb-announce/2010/msg00003.html
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi Alexander. I've looked into the problem and the linker error is
caused by a mix of stack protector options between libgcc and the C
library.
GCC includes a feature called the stack smashing protector which
detects writing past the end of a stack based object. It's quite nice
as it gives decent protection against buffer overruns which are the
most common type of security vulnerability.
The implementation is straight forward: when compiled with
-fstack-protector, any function with a stack-based character array
will have extra stack checking code inserted into the prologue and
epilogue. The prologue allocates a canary value at the top of stack
and fills it in with the value of '__stack_chk_guard' provided by
libssp. The epilogue checks this value and calls `__stack_chk_fail`
if it has been changed. The stack protector can interfere with some
code and isn't applicable in others.
The problem here is caused by a stack up of things:
* glibc knows about -fstack-protector and turns it on and off for
different functions and libraries
* gcc knows about -fstack-protector and includes libssp if required
* glibc knows about libgcc and statically links against it to ensure
availability
* Meego seems to turn on -fstack-protector by default (as does Ubuntu)
This results in the libgcc function '_gcc_Unwind_Backtrace' being
built with the stack protector and the glibc library 'libanl' without.
At static link time GCC sees that the stack protector is off and
skips linking against libssp, causing the missing symbol error.
The solution is to add -fno-stack-protector to the libgcc build
options and rebuild the compiler. I've heard (but can't track down
the link) that the ARM libgcc unwind functions must be built this way
in any case.
See
http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-d…
for how Debian does this.
Hope that helps,
-- Michael
On Fri, Aug 27, 2010 at 9:06 PM, <Alexander.Kanevskiy(a)nokia.com> wrote:
> Hi Michael.
>
> I've created for you account in MeeGo OBS (build system that we use in MeeGo
> is OpenSuSE build system)
>
> login: michaelh
> password: wog-feg-da
> Web client url: https://build.meego.com
> API url: https://api.meego.com
>
> The build log that had problem with glibc 2.12 + gcc 4.5 you can find here:
>
> https://build.meego.com/package/live_build_log?arch=armv7el&package=glibc&pr
> oject=home%3Akad%3Abranches%3ATrunk%3ATesting&repository=standard
>
> Might be you have some idea what went wrong, as our toolchain people were
> not able to find why combination of latest gcc plus glibc 2.11.x works, but
> not gcc 4.5 + glibc 2.12.0 :(
>
> This log is from my home project inside OBS, where stuff is already a bit
> outdated. I'll ask Jan-Simon from Linux Fundation to point to right place
> where latest builds are present, so you can experiment with them.
>
> --
> Best regards, Alexander Kanevskiy.
>
>
>
Hi all,
I've just discovered that Ubuntu is not using the Linaro release
information in the --version string. This is not ideal when we get bug
reports as it makes it hard to understand what Linaro release to use to
reproduce the issue.
Therefore, I've created a new wiki page to track the mappings:
https://wiki.linaro.org/WorkingGroups/ToolChain/VersionMappings
For now this only applies to GCC, but no doubt other tools will follow.
Please help keep it up to date if you find a version is missing. I've
added it to the GCC release process wiki page, so hopefully it should
get looked at at least once a month.
Andrew
