linaro-toolchain July 2013

linaro-toolchain@lists.linaro.org

22 participants
41 discussions

New IRC Channel for Linaro Toolchain Working Group

by Matthew Gretton-Dann

All, During Connect the suggestion was made that each working group should have its own IRC Channel for discussions and topics relating to the group in particular (as opposed to #linaro which is 'generic' Linaro conversations). Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain Working Group. This channel is public and open to anyone who wants to talk with the TCWG group about anything toolchain related. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro

2 years, 9 months

[ANNOUNCE] Linaro Toolchain Binaries 2013.07 released

by Zhenqiang Chen

The Linaro Toolchain and Platform Working Groups are pleased to announce the 2013.07 release of the Linaro Toolchain Binaries, a pre-built version of Linaro GCC and Linaro GDB that runs on generic Linux or Windows and targets the glibc Linaro Evaluation Build. Uses include: * Cross compiling ARM applications from your laptop * Remote debugging * Build the Linux kernel for your board What's included: * Linaro GCC 4.8 2013.07-1 * Linaro Newlib 2.0 2013.06 * Linaro Binutils 2.23 2013.06 * Linaro Eglibc 2.17-2013.07-2 * Linaro GDB 7.6 2013.05 * A statically linked gdbserver * A system root * Manuals under share/doc/ The system root contains the basic header files and libraries to link your programs against. Interesting changes include: * The sysroot is based on Linaro versions of Eglibc. About details of Linaro Eglibc, please refer https://releases.linaro.org/13.07/components/toolchain/eglibc-linaro. The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian 6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation 5.7 and later, and should run on any Linux Standard Base 3.0 compatible distribution. Please see the README about running on x86_64 hosts. The Windows version is supported on Windows XP Pro SP3, Windows Vista Business SP2, and Windows 7 Pro SP1. The binaries and build scripts are available from: https://launchpad.net/linaro-toolchain-binaries/trunk/2013.07 Need help? Ask a question on https://ask.linaro.org/ Already on Launchpad? Submit a bug at https://bugs.launchpad.net/linaro-toolchain-binaries On IRC? See us on #linaro on Freenode. Other ways that you can contact us or get involved are listed at https://wiki.linaro.org/GettingInvolved. Know issues: * Some version information in README are incorrect. * gdb can not backtrace into libc. Notes: * To use all of the features of Linaro eglibc, the sysroot in 32-bit toolchain release is updated to Linaro eglibc, which is 2.17. If you get runtime errors about libc version, please get the sysroot from the release tarball (gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/arm-linux-gnueabihf/libc/) or download from launchpad https://launchpad.net/linaro-toolchain-binaries/support/01/+download/linaro… If you do not want to use Linaro sysroot, you'd add option to gcc to find your sysroot: --sysroot=<directory> * To run 32-bit application built from arm-linux-gnueabihf toolchain in aarch64 system, you'd copy sysroot and runtime from release package to your root of aarch64 system. i,e. scp -r gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/arm-linux-gnueabihf/libc/* AARCH64-SYSTEM:/ scp -r gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_runtime/* AARCH64-SYSTEM:/

9 years, 4 months

[PATCH] omap_i2c: don't end I2C transfer immediately when STP bit is set

by Francesco Lavra

When the OMAP I2C controller is operated in master mode, setting the STP bit in the CON register instructs the controller to generate an I2C stop condition only after the programmed number of bytes has been sent on the I2C bus. The current code in QEMU ends the I2C transfer without first sending the pending data instead. Fix the above issue, and let the I2C transfer be ended in omap_i2c_fifo_run(), after the count of bytes to send has reached zero. Signed-off-by: Francesco Lavra <francescolavra.fl(a)gmail.com> --- Without this patch, the controller driver in Linux is unable to send data on the I2C bus, and when the controller triggers an IRQ after having started an I2C transfer, the XRDY flag in the STAT register remains always asserted, leading to an endless loop which eventually results in a kernel oops. hw/i2c/omap_i2c.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/hw/i2c/omap_i2c.c b/hw/i2c/omap_i2c.c index cfaac07..17d4037 100644 --- a/hw/i2c/omap_i2c.c +++ b/hw/i2c/omap_i2c.c @@ -521,10 +521,6 @@ static void omap_i2c_write(void *opaque, hwaddr addr, omap_i2c_fifo_run(s); } omap_i2c_interrupts_update(s); - } else if (value & 2) { /* STP, but not STT */ - i2c_end_transfer(s->bus); - s->control &= ~0x0602; /* MST | TRX | STP */ - s->count_cur = s->count; } } break; -- 1.7.5.4

10 years, 8 months

[ACTIVITY] 22-26 July2013

by Venkataramanan Kumar

== Progress == * Libssp support for AArch64 TCWG 23 Discussed with Matt and decided to assume "glibc" will export canary guard variable in TCB, for aarch64. It will export it as global variable for 32 bit. Working on top of Christophe patch that make frame grows downward. * Look at builtin return address behavior in the absence of frame pointer. For X86_64 usage if __builtin_return_address(n) n>0 and -fomit-frame-pointer results in undefined behavior. In Ubuntu 12.04 the native GCC 4.7.1 resulted in segmentation fault on x86_64 machine for such a test. Currently planning to close this as undefined behavior in aarch64 as well. Discussing with Marcus on this. * TCWG-20 gprof support patches. Re based with latest trunk and regression tested. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01352.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01333.html Misc * Tuesday spent on Internal (AMD) work. == Plan == * Continue Libssp support for AArch64 TCWG-23 * Update review comments and upstream gprof patches ==issues== * LTO/PGO work stopped now since libssp support priority is more.

10 years, 8 months

[ACTIVITY] 22 - 26 July 2013

by Omair Javaid

== Progress == * Completed initial investigation on catch syscall support on arm TCWG-182. * Looked into dwarf assembler to generated architecture independent debug information for dwarf2 test cases. * Resolved some gdb.mi configuration issues due to which some test cases were failing. * Review status of GDB testing on arm and filled up JIRA with proposed future work. == Plan == * Continue work on gdb catch syscall support for arm TCWG-182. * Background task: Understanding dwarf assembler to generate dwarf2 debug information for architecture test cases. * File UK visa for meetings in September after receiving invitations.

10 years, 8 months

[ACTIVITY] June 22-28

by Rob Savoye

== Progress == * Produced spec2000 benchmark data on panda for fsf-4.7, fsf-4.8, gcc-linaro-4.7, and gcc-linaro-4.8. * Helped Charlie get stared with building the toolchain. * Found "experimental" option that got crosstool-ng actually working. * Got cbuildv2 now doing much of the process crosstool-ng does for a complete stage1 build. * Improved native and cross toolchain builds via cbuildv2. == Plans == * Continue working on cbuildv2 till it's usable by others. * Looks like I have a pile of new wiki pages to write.

10 years, 8 months

[ACTIVITY] Week 30

by Zhenqiang Chen

== Issues == * None == Progress == * Prepare Linaro toolchain binary 2013.07 release. * Follow-up patches for pr57637. * Test conditional compare changes based on trunk. == Plan == * Release Linaro toolchain binary 2013.07. * Send out the conditional compare changes for Linaro internal review.

10 years, 8 months

[ACTIVITY] Week 30

by Charles Baylis

== Progress == * Induction and set up work environment * Started investigating how to build gcc cross compilers, so that it can be documented clearly [TCWG-190 <http://cards.linaro.org/browse/TCWG-190>] * I can build a working arm-none-linux-gnueabi crosscompiler, and understand each of the steps involved * Using the same method, aarch64-none-linux-gnu does not build == Issues == * None == Plan == * Write up knowledge gained so far * Find out why aarch64 doesn't work * Find out more about other build variations (multilib/multiarch etc) and how that affects what I've done so far

10 years, 8 months

[ACTIVITY] Week 30

by Will Newton

== Progress == * Backported aarch64 string functions and ARM gcc 4.8 fix in eglibc. * Released eglibc 2.17 2013.07-2. * Forward ported binutils AArch64 IFUNC patches to HEAD so Marcus can test them. * Closed stack guard JIRA card and made a new one for pointer guard. * More malloc benchmarking, reading etc. * Started work on malloc code. * Booked flights for LCU13! == Issues == * None. == Plan == * Deal with any test feedback on IFUNC patches. * malloc -- Will Newton Toolchain Working Group, Linaro

10 years, 8 months

[ACTIVITY] Week 30

by Renato Golin

== Progress == * Looking at 64-bit divmod on two fronts: - Clean, but intrusive on target-independent code - Dirty and duplicated, but restricted to target-specific code * Long discussion about the purpose of the IR on the LLVMLinux list * Watching some GNU Caldron videos == Plan == * Continue looking at divmod for 64-bit values * Start investigating cross-compilation issues * When Rob is ready, have a look at CBuild2 for LLVM+Benchmarks

10 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain July 2013