linaro-toolchain

linaro-toolchain@lists.linaro.org

16 participants
5599 discussions

by Zach Welch

== Last Week == * Spent time tracking down a couple of regressions that appeared in the new ltrace release-candidate tree. Submitted a bunch of patches to fix the issues that were discovered during that process; most have been applied. * Finished writing fairly generic code for handling ARM-specific unwind tables, from lookup through decoding and dispatch. It uses a few definitions specific to libunwind, but those probably could be eliminated with more work. == This Week == * Integrate new ARM-specific bits into libunwind framework. * Rewrite part of a portability patch for ltrace and hope that those changes reflect the very last effort that will be required for that particular task. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

14 years, 6 months

Re: Neon registers in core files

by Dave Martin

On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi <yao.qi(a)linaro.org> wrote: > Hi, Kernel WG, > Can recent kernel handle NEON registers in corefiles? > > Seems we've had plan for this in "Ensure full NEON debug support" in > https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Specs/BSPInvestig… > Any progress on this piece of work? We want to handle NEON registers in > corefiles from GDB, which required kernel dump them in corefile first. Hmmm, actually that bullet may have ended up in the wrong place ... since it's not a BSP-specific feature. Anyway, looking at the kernel code, it looks like the VFP/NEON state is not dumped into the core file. If it makes you feel better, the state of the obsolete FPE extension registers is dumped, if used :/ My guess is that it shouldn't be hard to dump the VFP/NEON state, but GDB and the kernel need to agree on the format. Rather that trying to hack the existing register dump format in a compatible way, I suggest it's simplest if the kernel creates an extra section in the dump containing something like: .long format_version /* reserved for future expansion - must be 0 */ .long FPSID .long FPSCR .long MVFR0 /* or 0 if not present in the hardware */ .long MVFR1 /* or 0 if not present in the hardware */ .long d0 .long d1 /* ... d2-d14 ... */ .long d15 If 32 D-registers in the hardware [ .long d16 .long d17 /* ... d18-d30 ... */ .long d31 ] I believe we don't need any extra flags to indicate whether the MVFRx fields are valid, since 0 in these registers indicates the VFPv2/legacy behaviour anyway. Note that some VFPv2 implementations (such as ARM1176) do provide these registers, and where the hardware has them, the kernel can fill them in when doing the coredump. We _should_ be prepared to ignore these fields (or interpret them differently) if a vendor-specific VFP subarchitecture is specified (by (FPSID & 0x4000) == 0x4000) The number of D-registers can be deduced from the FPSID and MVFRx registers, so we don't need to record it explicitly. When MVFRx are not present, there are 16 D-registers. When MVFRx are present, and (MVFR0 & 0xF) >= 2, there are 32 (or more) D-registers This is just a sketch -- the ARM ARM is the authoritative reference on the meanings of these bitfields. Any views on this? Cheers ---Dave > > _______________________________________________ > linaro-dev mailing list > linaro-dev(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev >

14 years, 6 months

[ACTIVITY] Dec 6 - Dec 10

by Ulrich Weigand

== GCC == * Tracked down root cause of GCC mainline bootstrap failure on ARM (PR 46040 - "__DTOR_LIST__ undeclared"). == Miscellaneous == * Set up IGEP v2 board (w/ local disk, network, ...) as native GCC / GDB build environment. * Gave talk on Linaro at the "2010 Linux Community Event" at Siemens Munich (w/ Arnd Bergmann). 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, 6 months

Invitation: TWG GCC Optimization @ Wed 2010-12-15 9am - 10am (linaro-toolchain@lists.linaro.org)

by Andrew Stubbs

You have been invited to the following event. Title: TWG GCC Optimization Discuss ideas for improving GCC optimization for ARM. Open to anybody who wants to contribute. https://wiki.linaro.org/AndrewStubbs/Sandbox/GCCoptimizations International: +44 1452 567 588 UK: 0844 493 3801 Brazil: 08008912092 China: 108007121533 India: 0008001006354 Taiwan: 00801126472 United States: 18666161738 Conference code 2634417169# When: Wed 2010-12-15 9am – 10am London Where: Conference call code 263 441 7169 Calendar: linaro-toolchain(a)lists.linaro.org Who: * andrew.stubbs(a)linaro.org - creator * Ken Werner - optional * stevenb.gcc(a)gmail.com - optional * Michael Hope - optional * David Gilbert - optional * Peter Maydell - optional * ulrich.weigand(a)de.ibm.com - optional * Yao Qi - optional * Julian Brown - optional * paul(a)codesourcery.com - optional * Ira Rosen - optional * richard.earnshaw(a)arm.com - optional * Chung-Lin Tang - optional * mark(a)codesourcery.com - optional * linaro-toolchain(a)lists.linaro.org - optional * Richard Sandiford - optional * Marcin Juszkiewicz - optional * zwelch(a)codesourcery.com - optional Your attendance is optional. Event details: https://www.google.com/calendar/event?action=VIEW&eid=aXJlc2Z2bWZmZzQ5cGQ4b… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account linaro-toolchain(a)lists.linaro.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

14 years, 6 months

[ACTIVITY] Dec.6th -- Dec.12th

by Chung-Lin Tang

== GCC related == * PR44557, Thumb-1 ICE: found two small needed corrections in the ARM backend to fix this. Sent patch upstream. * LP:641397/PR46888: bitfield insert optimization. Posted patch along with Andrew Stubbs' CSE patch upstream. The two-patch situation seemed to stir some discussion :) It seems both patches were deemed okay, though it would be better if there was some testcase that passed through unhandled by Andrew's CSE patch, but processed by my combine fix later in the pass pipeline. Both patches queued at GCC bugzilla page, to be handled in the next stage1. * LP:687406/PR46865, -save-temps creating different code. Analyzed problem, though slow to send fix upstream. Had some discussion on the list on how the fix should be like. * PR46667, section type conflicts. Tested and sent mail to gcc-patches. Jan Hubicka picked it up and pinged for an approval again. Hope this get resolved soon. * PR45416, ARM code regression. ARM considerations are mostly okay, main issue remaining is how to solve the x86 regression. The current expand code does a full DImode shift just to obtain a single bit, might be point of improvement to solve this. * LP:685534, ftbfs with gcc-linaro 4.5 on amd64. Found to be another erroneous inline asm case. Fixed and updated on LP. == This week == * More upstream and Linaro GCC issues. * Start dealing with January travel. * Think more about larger (Linaro) GCC optimization projects.

14 years, 6 months

[ACTIVITY] Dec 6th -- Dec 12th

by Yao Qi

== Linaro GDB == * LP:616000 Handle -fstack-protector prologue code Understand how frame affect expression validation in GDB. Improve i386 prologue parsing to handle 'and/add' sequence. Revise i386 prologue parsing for stack protector. Patch is not submitted since still lack of i386 prologue knowledge, and not very confident on that patch. Understand prologue-value used in ARM prologue parsing and relationship of symbol and frame in GDB. Make ARM prologue parsing understands stack protector code by identify the code sequence. Improve the patch by supporting ARM mode and ARMv5T, in order to make this patch accepted by upstreams. * LP:615972 gdb.base/gcore.exp failure. The failure is about "corefile restored general registers", which is not related to NEON register support in corefile. It is caused by inconsistent register types and names between tdesc and arm. The cause of this failure is found, but upstreams reviewer doesn't agree on one of my fix. As he suggested, arm-core.xml is modified to add "type=XXX", but get some errors when regenerate arm-with-iwmmxt.c. Filed GDB PR 12308. == GCC == * register rename improvements (LP:633243) Finally, got both middle-end part and ARM part approved. Committed to upstreams mainline. Some benchmarks in EEMBC shows 0.1%~0.2% code size reduction. == This Week == * Ping my GDB patches. * Fix GDB PR 12308, which blocks my fix for LP:615972. * Backport my approved patches to Linaro GDB if any. Fix other GDB bugs. * Pass one GCC patch in my queue to review, if I have extra time. == Vacation == Take vacation on Dec 30th and 31st. Travel to ChengDu, and back on 3rd Jan (It is public holiday in China). Back to work on 4th Jan. -- Yao (齐尧)

14 years, 6 months

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Away Monday and Tuesday. * Very little the rest of the week due to other IBM commitments. I've just finished the main part of that work, so all being well, it should only need a bit of nannying next week. Most of the week should be Linaro. * Started trying to reproduce #641126, but realised that I'd need to set myself up for general Ubuntu cross package building first. Started to look at what's involved. == Next week == * Get stuck into #641126. * More STT_GNU_IFUNC and vectors. Richard

14 years, 6 months

[ACTIVITY] report week 49

by Peter Maydell

RAG: Red: Amber: Green: Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | postponed | | get valgrind into linaro PPA | 2010-09-15 | 2010-09-28 | 2010-09-28 | complete a qemu-maemo update | 2010-09-24 | 2010-09-22 | 2010-09-22 | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | Progress: * merge-correctness-fixes: ** I have sent out an updated ARM fixes pull request, all of whose components have been Reviewed-by: Nathan Froyd; I expect this to be merged shortly. ** vqshl(reg) patch posted to list; I have an update which also addresses vqshl{,u}(imm) which I'll send out as v2 once the first part has been reviewed. ** reviewed and retransmitted Wolfgang's semihosting commandline patches since he is having trouble sending unmangled mail to the list ** went through the monster qemu-maemo commit "Lots of ARM TCG changes" http://meego.gitorious.org/qemu-maemo/qemu/commit/3f17d4e1cb identifying what fixes it includes ** started looking at a VRSQRTS patch. This uncovered a number of qemu issues: NaN propagation is wrong, flush-to-zero handling is only flushing output denormals, not input denormals, and we don't handle the Neon "standard FPSCR value" but always use the real FPSCR. I have some preliminary patches for at least some of this, but since they affect a number of the same bits of code that are touched by existing not-yet-committed patches I'm waiting for those to be committed first. * verify-emulation: ** wrote a README for risu and made it public at http://git.linaro.org/gitweb?p=people/pmaydell/risu.git;a=summary * maintain-beagle-models: ** the ubuntu maverick netbook image doesn't boot on qemu because it uses the OMAP NAND prefetch/DMA, which isn't modelled https://bugs.launchpad.net/qemu-maemo/+bug/645311 I've started on this and am perhaps halfway through (basic prefetch code implemented, but DMA and debugging still to go) * other: ** took part in an OBS mini-sprint where we were walked through how the OBS buildsystem works and can be used to do test rebuilds of Meego with new versions of the toolchain. Meetings: toolchain, pdsw-tools Plans: * finish omap NAND prefetch engine work * make sure ARM changes get committed to qemu... Absences: (complete to end of 2010) Fri 17 Dec - Tue 4 Jan inclusive. 2011: Dallas Linaro sprint 9-15 Jan. Holiday 22 Apr - 2 May.

14 years, 6 months

[ACTIVITY] weekly status

by Ken Werner

Hi, * created custom kernel deb packages from the linaro-linux tree in order to * test the various ftrace tracers and profilers available on ARM * results at: https://wiki.linaro.org/KenWerner/Sandbox/ftrace * started to look into crash (kexec, kdump) but wasn't able to generate a kernel dump yet Regards Ken

14 years, 6 months

Perfromance Test Results using gcc-linaro-4.5-2010.11-1

by Prashanth S

Dear All Our team in Samsung collected some performance metrics for the following 3 GCC cross compilers 1.. Gentoo Complier(part of Chrome OS Build Environment) 2.. GCC 4.4.1 (Code Sourcery). 3.. Linaro (gcc-linaro-4.5-2010.11-1) Flags used to Build Linaro Tool chain used Michael Hope Script .Just modified "GCCFLAGS = --with-mode=thumb --with-arch=armv7-a --with-float=softfp --with-fpu=neon --with-fpu=vfpv3-d16" a.. Using the above three tool chains we compiled the kernel of Chrome OS and did Coremark Performance test.(With same optimisation flag mentioned in the attachment) b.. Test Environment for all the three are the same. My Questions 1.. Is there any build options that I am missing while I am building the Cross Compiler? 2.. Else is this performance degradation is a know issue and is the tool chain group working on it?.(If so whom to contact?) Any Pointers from you would be of great help to me. If you need any further details also do ping me Regards Prashanth S

14 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain