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
