Current state of the Linaro toolchain
This is an open session to discuss the current state of the Linaro toolchain, our outputs, and what could be improved.
Whiteboard
The next six months:
* GCC
* GDB
* Library tuning
* OpenOCD
* Binutils related performance
* Developer tools
Review of upcoming sessions:
Future Linaro toolchain areas
Tuesday:
Toolchain consumption models
Cross-compilation environment
Using QEMU for demonstration
LTTng
gdbserver
Current and future GDB plans
Wednesday:
Eclipse CDT support
ARM cross-compiler packages
Thursday:
NEON/vectoriser direction
Performance inside GCC
ARM specific library tuning
Performance outside GCC
Friday:
OpenOCD
Hard float
People's main areas
Rotation into other areas
Priorities
Scheduling
Particular blueprints
- Current state of Linaro toolchain
* 2010.10 release http://
* Linaro GCC:
* Linaro GDB: Better test suite pass rate on ARM and even on x86, compared with FSF GDB 7.2. (Can we claim on this?)
* Valgrind: "developer preview" http://
* ltrace:
- To be improved
* Linaro GCC
** Performance is one of our focus, and can be better. How to keep performance advantage against FSF GCC? How to avoid speed regression?
** .....
* Oprofile: (need kernel support)
* QEMU: Performance?
* Actively collect feedback from users. We've done a lot of things, such as bug fix, performance tuning, and new features development, but we don't know how much benefit users get from our work, for example,
** When code size optimization implementation is done, can we measure how much code size is reduced on linux kernel and other application?
** When neon auto-vect is done, how this enhancement benefit other applications?
- Near term areas:
* LTO - get it up and running, get it robust
* PGO - get it up and running
