linaro-toolchain

linaro-toolchain@lists.linaro.org

7 participants
5622 discussions

by Ken Werner

== libunwind == * Had few discussions with Uli with regard to unwinding. * Continued to learn about libunwind internals. * The .ARM.exidx and .ARM.extbl section parser is functional but the integration into libunwind needs to be improved. Currently there are two seperate models that hold the informations of the current frame. Since they are not synchronized the behavior of libunwind is quite unexpected to the user. * I started on eliminating the redundancy by removing the model that was introduced for the extbl support. My goal is to have the parser operate on the DWARF model directly. In theory this should also allow to mix DWARF- and extable-frames. Regards Ken

14 years, 5 months

[Activity] March 7 - 18

by Ramana Radhakrishnan

== GCC == * Started looking at performance regressions. Setting up builds with EEMBC Denbench and other benchmarks. * Looked at PR47719 in some detail this week. * Set up environment on laptop . Fixed PR46788 in 4.6 branch and trunk. * Discussions regarding armhf, how to maintain Linaro branches - upstreaming patches etc. * Looked at a case of performance improvements with VFP stores. I think it's because we end up allowing PRE_INC and POST_DEC for floating point mode values because of which there end up being more transfers to and from the integer core registers. * Off sick on Monday 14th March 2011. == Misc == * Sorted out travel arrangements for LDS. Waiting for visa now.

14 years, 5 months

[ACTIVITY] Mar 14 - Mar 18

by Ulrich Weigand

== GDB == * Ongoing work on glibc patch to add ARM unwind tables to system call stubs (bug #684218). * Implemented initial version of a kernel patch that fixes GDB inferior calls while stopped in a restartable system call (bug #615974); started discussion with kernel folks. * Implemented new version of patch to fix single-stepping over signal handlers (bug #615978) that addresses review comments; posted to mailing list. * Verified Linaro GDB patch set can be applied to Ubuntu package. 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

14 years, 5 months

[ACTIVITY] report week 11

by Peter Maydell

(sent early this week since I'll be in the conference all Friday) RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | Historical Milestones: [trimmed the 2010 ones] finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * wrote most of a patch to properly implement prlimit64 syscall in usermode -- needs checking/testing * wrote most of a patch to allow boards to specify their min/max/default RAM size rather than having a single qemu-wide default; this would let us specify RAM size on the beagle model (currently hardwired) * retested the patch I wrote late last year which fixes TCG's locking problems by having interrupting signals/threads just set a flag which we check in every TB (rather than trying to mess with the TCG graph in a totally unsafe and crashprone way). Slowdown: about 3.5% on "boot Linaro nano on vexpress to rootprompt and shutdown again". I shall see if I can persuade people that this is a price worth paying for not randomly crashing in thread-heavy code :-) == merge-correctness-fixes == * Wrote/submitted patchset which fixes VRECPS edge case handling (mostly NaN related) * Wrote/submitted patchset which fixes Neon VLD of single element to all lanes * Wrote/submitted patch which fixes qemu to work on an ARM host where the host C code has been built in Thumb mode == other == * attended QEMU Users Forum in Grenoble * meetings: toolchain, standup, pdsw-tools, arch q&a Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver

14 years, 5 months

[ACTIVITY] 2011-03-17

by David Gilbert

Short week * libffi patch accepted upstream * eglibc integration of string routine changes - I have something that works but it's more complex than I'd like (to get it to fall back to the C code on stuff I haven't optimised for). * Trying a neon memchr; tried a really simple 8 byte a loop version - it's quite slow on both A8 and A9; branching on the result of comparisons done in the neon is not simple. * Porting jam bug 735877 chromium using d32 float; it was passing vpfpv3 rather than using the default when configured without neon. On holiday tomorrow (Friday). Dave

14 years, 5 months

[ACTIVITY] March 13-17

by Revital1 Eres

Hello, Experiment with aes benchmark from DENbench. Continue my experiments with SMS which includes re-implementing an old patch to insert reg-moves in free slots rather than greedily before the definition as is done in the current implementation. Thanks, Revital

14 years, 5 months

[ACTIVITY] March 13-17

by Ira Rosen

Hi, * submitted store sinking patch to mainline * started testing auto-detection of vector size patch * DENBench - some benchmarks are still unstable, I am looking into stable regressions, adjusting and fixing the cost model for them Next week: Sunday and Monday - holidays Ira

14 years, 5 months

Versatile Express write-up

by Michael Hope

Here's a end-of-cycle write up for Versatile Express support in QEMU: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMUVersatileExpress Most of it is taken from Peter's page: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress which is the place to go if you want the current state and more detail on the steps involved. While writing this up I had a seamless experience from the first linaro-image-create until seeing the alpha3 greeter come up and wobbling the mouse around. It was awesome. Some ideas for other write-ups at: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs -- Michael

14 years, 5 months

RealView PBX write-up

by Michael Hope

Dave did an investigation earlier in the year into Cortex-A9 and RealView PBX support in QEMU. The write-up is available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMURealViewPBX Dave and Peter: could you please review it? I've now closed out the blueprint. I'd like to do similar reports on other outputs and will attack vexpress next. -- Michael

14 years, 5 months

Work-item tracking for the "gcc-linaro-tracking" LP project

by Ulrich Weigand

Hi Michael, Andrew, Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro, gdb-linaro etc.) are now also included in the LP work-item tracking statistics (http://status.linaro.org/linaro-toolchain-wg.html). This didn't happen in the past due to a Launchpad issue that has now been fixed. This seems to be working out nicely, except for one issue: what about the gcc-linaro-tracking project? I have a couple of bugs that are fixed in Linaro GCC, and are also fixed in mainline GCC, but they still show up as an "in-progress" work-item in the status tracker (there are a whole bunch more of those assigned to Andrew as well). The reason for this is the LP records have an associated gcc-linaro-toolchain project entry, and this is set to "Fix Committed", but not "Fix Released" ... probably because GCC 4.6.0 is not yet released? Now, on the one hand it does make sense to include the -tracking project in the work-item statistics, because they *do* reflect important tasks: namely, to make sure that the changes indeed land in the upstream repository. However, having them all show up as "in progress" until the community makes a new GCC release does not seem very helpful: this is not in our control, and our work is in fact done once the patch is committed upstream. Therefore my suggestion: we should immediately mark -tracking bugs as "Fix Released" (not "Fix Committed"), as soon as the corresponding patch is committed upstream (and thus our work on the problem is completed). Thoughts? Does this make sense? Will this mess up any of the other purposes for which we currently use the -tracking project? 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

14 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain