The Linaro Toolchain Working Group is pleased to announce the 2010.10
consolidation release including Linaro GCC 4.4, Linaro GCC 4.5, and
the first version of Linaro GDB 7.2.
Linaro GDB 7.2 2010.10-0 is the first release in the 7.2 series. Based
off the latest GDB 7.2, it includes a number of ARM-focused bug fixes
and enhancements.
Interesting changes include:
* Backtraces in Thumb-2 code are significantly improved
* Much better prologue and epilogue parsing
* Improved software watchpoint support
* Many test suite tidy-ups
Linaro GCC 4.5 is the third release in the 4.5 series. Based off the
latest GCC 4.5.1+svn, it includes many ARM-focused performance
improvements and bug fixes.
Linaro GCC 4.4 is the fourth release in the 4.4 series. Based off the
latest GCC 4.4.5, it fixes many of the issues found during building
Ubuntu over the last few months.
Interesting changes include:
* Linaro GCC 4.4 is now based off FSF GCC 4.4.5
* Cortex A8 and Cortex A9 scheduler NEON improvements
* Better code generation for constant addresses with inline assembly
* Better code for copying small constant strings
* Various correctness improvements
Downloads are available from the Linaro GCC and GDB pages on Launchpad:
https://launchpad.net/gcc-linarohttps://launchpad.net/gdb-linaro
-- Michael
Hi all,
I was wondering someone knows about a ARM DCC (debug
communications channel) device driver.
The idea is to run gdbserver on /dev/dcc such that application
debugging does not hog a serial/ethernet port.
I'd modify OpenOCD to forward the DCC onto a TCP/IP port
to connect GDB to the gdbserver.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
(cc'ed to linaro-toolchain, bcc'ed to others who may be interested)
I'm considering adding a new Linaro Toolchain meeting to cover people
in the North/South American timezones. We've got quite a few people
in that area who are interested in the toolchain but can't make the
current 0900 UTC calls.
How about a weekly half-hour call on Wednesdays at 1800 UTC? Once
daylight savings drops out on the 7th of November, this would be 1000
Sacramento/PST, 1200 Houston/CST, and a reasonable evening time for
those in Europe who wish to join.
This will be a technical call and can cover topics such as status
updates, release plans, reported problems, and any input from
toolchain users.
Please send me an email if you are interested,
-- Michael
Hi Marcin. Would you consider passing
--enable-poison-system-directories to the cross compiler configure?
This makes the '-Wpoison-system-directories' option available which
warns you if the cross compiler picks up a library or header file from
/usr instead of the cross-build environment.
I'm talking with someone who's looking at using the Linaro compiler
and had a strange error due to picking up the host crtn.o. Having
this warning would of tracked down the problem faster.
-- Michael
I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
verified this by doing objdump on libgcc.a and I see combinations of
16 and 32 bit instructions. So does that mean that the toolchain is
only usable for ARM versions that support Thumb-2?
Thanks,
John
As discussed in the meeting yesterday, CodeSourcery has a few MinGW
patches that I had not merged into Linaro GCC.
I have now investigated these patches, and I'm fairly happy that most
are not necessary for Linaro. They're mainly about interworking with Cygwin.
The one exception is this one:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01214.html
(and even that is primarily a GDB issue).
Andrew
I made a patch for ltrace that adds support for Thumb-2. There's not
much to it, but it allows me to trace applications built for Cortex-A8.
Without it, users will experience this bug:
https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/639796
Unfortunately, it appears that the upstream tree is not well-maintained.
I posted it to the mailing list for the project, but others' patches
have been ignored for many months. However, my post precipitated another
contributor to offer to maintain the package.
I also posted this patch as the proposed solution for the above LP bug,
which should allow Linaro to benefit from the work without worrying
about upstream. In fact, a new version of the package appears to have
been released that includes my patch (0.5.3-2ubuntu6). Please give this
updated package a whirl and let me know if there is more work to be done.
Thoughts? Unless I hear feedback from others, I will assume that this
tool now works for Cortex-A[89] and move on to other tasks.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
(this is for current Toolchain WG members. Sorry if I got anyone
else's hopes up)
We'll soon be coming into some decent dual-core Cortex-A9 boards that
have 1 GB of RAM and a good set of USB ports. I've asked for four of
them with hard drives to go into the data centre for general use.
Would anyone also like one for their desk? Note that you're generally
better off using a data centre board as it's one less thing to
maintain.
-- Michael
Hi
I finally built armel cross compiler packages for Ubuntu 10.04 'Lucid' LTS.
They are available in unsigned APT repository:
deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./
They are built from Maverick packages:
- binutils-source
- eglibc-source
- gcc-4.4-source
- gcc-4.5-source
- linux-source-2.6.35
- armel-cross-toolchain-base
- gcc-4.4-armel-cross
- gcc-4.5-armel-cross
So they do not give exactly same versions as compilers used in 10.04 - please
remember about it while doing cross builds.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Hi folks
apparently some tool calls "strip" instead of "$triplet-strip" when
cross-building; this is something we shall fix, but it is apparently
corrupting the binaries in some cases:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/615765
It seems the ELF architecture isn't set properly, or so I'm told.
Which component is to blame here? Are we looking at a binutils or a
gcc bug for not being able to set or read enough data that the
architecture mismatch isn't detected? What could we do about it?
Thanks!
--
Loïc Minier
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
