== GDB ==
* Ongoing work on remote support for "info proc" and core file
generation. Completed implementation of latest solution
via accessing arbitrary files on the remote site, only to
run into a fundamental design problem ... so it's probably
back to the previous approach. Discussion on the list is
ongoing.
* Fixed a GDB 7.4 test suite failure on ARM: PR tdep/12797
* Fixed another GBD 7.4 test suite failure on ARM, by enabling
pthread_t thread debugging on core files.
== GCC ==
* Patch review week.
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 there. I've looked further into the intermittent
gcc/testsuite/g++.dg/cdce3.C test failures. Taking Ira's
vectoriser-only fix-pr51301-4.6 branch and comparing it with it's
predecessor r106845:
* cdce3.o itself is identical across compilers
* Fault occurs in a parallel test run as part of the normal auto build
* Fault occurs every time
* Fault occurs with a manual 'make check-gcc RUNTESTFLAGS="dg.exp=cdce*'
* Fault doesn't occur when building from the command line
* Fault doesn't occur after updating binutils
I'm suspicious of the linker. The auto builders are Natty based and
come with ld 2.21.0.20110327. Updating them to Oneiric's
2.21.53.20110810 clears the problem.
I've saved the build trees. I see no reason not to commit
~ramana/gcc-linaro/fix-lp-900426 and ~irar/gcc-linaro/fix-pr51301-4.6.
-- Michael
== GDB ==
* Ongoing work on remote support for "info proc" and core file
generation. Implemented initial version of latest solution
via accessing arbitrary files on the remote site.
== GCC ==
* Started familiarizing myself with current status of various
performance patches in programm, in preparation of my taking
on GCC performance work next year.
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
Summary
* make check-gcc on windows.
* crosstool-ng patches
Details:
1. Two patches for crosstool-ng:
* Fix the compile error when CT_USE_SYSROOT is not "y". With this
fix, we can config crosstool-ng to remove the symbol link for windows
build.
* Add scripts to build manual for newlib.
2. make check-gcc on Windows:
* Wrap gcc/g++ for windows test. testglue.c should be compiled with
gcc not g++.
* Enhance scripts to convert path using "cygpath -w"
3. Analyze and root cause the pseudo new failed cases on windows.
* gcc fail cases (gcc.dg/cpp/assert3.c, gcc.dg/cpp/include7.c and
gcc.dg/cpp/trad/assert3.c)
Root cause: " in options are removed in the test scripts. e.g.
When reading gcc.log, you can find “-Aabc = jkl” in "Executing
on host" as:
Executing on host: …/cpp/assert3.c -A abc=def -A abc(ghi)
"-Aabc = jkl" …
But in spawn: the “” are removed.
spawn …/cpp/assert3.c -A abc=def -A abc(ghi) -Aabc = jkl
* g++ fail cases (dwarf2/lineno-simple1.C, dwarf2/pr44641.C and
dwarf2/pr46527.C)
The assembler codes generated from windows g++ and linux g++ are
same except the PATH string. And all PASS on linux test.
It seams the scripts can not grep the expected string on windows.
* Tests on windows are not stable. For each test, there will have
random fail cases (pass when retesting separately).
Plans:
* Create Makefile for embedded toolchain in linaro crosstool-ng.
Best regards!
-Zhenqiang
Hi,
I was just wondering if anyone knows of any current or future dependencies with the Linaro toolchain (2011.11) and the Linaro release of GDB and the Linux Kernel?
Is it considered safe to use the toolchain with the upstream releases of GDB and the Kernel, assuming that the versions of each are suitably compatible?
Or are there potential dependencies on work that has been done in the toolchain? For example, new instructions supported in the compiler/assembler, or enhancements to the kernel/runtime library on the Linaro branch that would depend on them being in sync.
Thanks,
Dave.
Hi,
OpenEmbedded-Core:
* the CSL 2011.03 recipe works with localization support disabled
* got the OE-Core sato image to built (~250 source packages)
* also built the Qt4 demo image (~100 source packages) to stress the
C++ part of the toolchain
* both are booting using qemu and seem to work just fine.
* all of the Linaro members approved the request to contribute to
OpenEmbedded
* started to post patches onto the mailing list
* briefly looked at the Linaro binary toolchain
* the most recent one is dynamically linked
* while the old one has old binutils (.21) that causes issue with
--gc-sections
* Currently the build is using the OE qemuarm machine configuration that
uses a Yocto kernel and targets armv5te. This is something I'd like to
look at too.
Regards
Ken
Continued work on 64-bit shifts.
- Improved 64-bit shifts without NEON (should benefit all cases).
- Fixed bugs in constant shift code.
- Rewrote 64-bit neon patch to take advantage of the new non-neon
code, in the fall-back case.
- Titied up the code, in general.
- Rewrote SImode shift amount patch for new neon patches.
The code produced now seems pretty good, but it still seems to choose
which mode to use slightly haphazardly. The next step is to figure that
out and benchmark the results.
Had a few more attempts at getting the LAVA system to do something
useful for me. I'm getting closer, but keep hitting new problems. Some
of them my fault, and some are bugs in the system. Paul Larson has been
very kindly helping me out and swatting the bugs.
Didn't get much further with benchmarking for the generic tuning. This
has been put on the back-burner while I work on the Neon shifts, and my
test runs on my IGEPv2 A8 board have all been interrupted by power cuts
or rendered useless by my forgetting to kill background tasks (such as
Xorg).
---- Next weeks
On vacation December 19th - January 3rd (returning January 4th).
== General ==
* Tidying things up and updating my list of statuses
== String routines ==
* Adding strchr and strlen to eglibc; tests running at the moment.
Dave
[short week, three days]
RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
||cp15-rework || 2012-01-06 || 2012-01-17 || ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| ||
(for blueprint definitions: https://wiki.linaro.org/PeterMaydell/QemuKVM)
Historical Milestones:
||add-omap3-networking || 2011-10-13 || 2011-10-13 || 2011-10-13 ||
||a15-systemmode-planning || 2011-10-13 || 2011-10-13 || 2011-09-22 ||
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
== cp15-rework ==
* estimate pushed back a bit because I've ended up doing this in
parallel with the other blueprints. Also exynos4210 review has
taken some time.
== upstream-omap3-cleanup ==
* split up the last handful of patches in the stack which were doing
several things at once
* this blueprint is now complete, meaning that the next stage of omap3
upstreaming will be cleaning up individual subsets of functionality
to send upstream. This is all backburner level priority, though.
== other ==
* reviewed most of Samsung's exynos4210 model
* completed a conflict-heavy rebase of qemu-linaro (the result of
MemoryRegion conversions for omap devices landing upstream)
* LP:903239 : added linux-user support for some missing xattr syscalls
that were causing build problems for apparmor
-- PMM
