- linaro-toolchain - lists.linaro.org

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, 5 months

3
2
0 0

[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, 5 months

1
0
0 0

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, 5 months

1
0
0 0

[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, 5 months

1
0
0 0

[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, 5 months

1
0
0 0

[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, 5 months

2
1
0 0

[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, 5 months

1
0
0 0

[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, 5 months

1
0
0 0

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, 5 months

5
6
0 0

GCC Optimization Brain Storming Session

by Andrew Stubbs

Hi All, As we discussed on Monday, I think it might be helpful to get a number of knowledgeable people together on a call to discuss GCC optimization opportunities. So, I'd like to get some idea of who would like to attend, and we'll try to find a slot we can all make. I'm on vacation next week, so I expect it'll be in two or three week's time. Before we get there, I'd like to have a list of ideas to discuss. Partly so that we don't forget anything, and partly so that people can have a think about them before the day. I'm really looking for bigger picture stuff, rather than individual poor code generation bugs. So here's a few to kick off: * Costs tuning. - GCC 4.6 has a new costs model, but are we making full use of it? - What about optimizing for size? - Do the optimizers take any notice? [1] * Instruction set coverage. - Are there any ARM/Thumb2 instructions that we are not taking advantage of? [2] - Do we test that we use the instructions we do have? [3] * Constant pools - it might be a very handy space optimization to have small functions share one constant pool, but the way the passes work one function at a time makes this hard. (LP:625233) * NEON - There's already a lot of work going on here, and I don't want it to hog all our time, but it might be worth touching on. What else? I'm not the most experienced person with GCC internals, and I'm relatively new to the ARM specific parts of those, so somebody else must be able to come up with something far more exciting! So, please, get brain-storming! Andrew [1] We discovered recently that combine is happy to take two insns and combine them into a pattern that matches a splitter that then explodes into three insns (partly due to being no longer able to generate pseudo-registers). [2] For example, I just wrote a patch to add addw and subw support (not yet submitted). [3] LP:643479 is an example of a case where we don't.

14 years, 5 months

9
10
0 0

[ACTIVITY] 2010-12-09

by David Gilbert

Mostly more working with libffi; swapping some ideas back and forwards with Marcus Shawcroft and it looks like we have a good way forward. Got an armhf chroot going, libffi built. Got a testcase failing as expected. Trying to look at other processors ABIs to understand why varargs works for anyone else. Cut through one layer of red tape; can now do the next level of comparison in the string routine work. Started looking at SPEC; hit problems with network stability on VExpress (turns out to be bug 673820) long long weekend; short weeks=2; Back in on Tuesday. Dave

14 years, 5 months

1
0
0 0

Silverbell

by David Gilbert

Hi, Those of you use silverbell may be glad to know it's back up. Be a little careful, if you shovel large amounts of stuff over it's network the network tends to disappear. (Not sure if this is hardware or driver) Dave

14 years, 5 months

1
0
0 0

Hard float chroot

by David Gilbert

Hi, As mentioned on the standup, I just got an armhf chroot going, thanks to markos for pointing me at using multistrap I put the following in a armhfmultistrap.conf and did multistrap -f armhfmultistrap.conf Once that's done, chroot in and then do dpkg --configure -a it's pretty sparse in there, but it's enough to get going. Dave ============================================== [General] arch=armhf directory=/discs/more/armhf cleanup=true noauth=true unpack=true explicitsuite=false aptsources=unstable unreleased bootstrap=unstable unreleased [unstable] packages= source=http://ftp.de.debian.org/debian-ports/ keyring=debian-archive-keyring suite=unstable omitdebsrc=true [unreleased] packages= source=http://ftp.de.debian.org/debian-ports/ keyring=debian-archive-keyring suite=unreleased omitdebsrc=true

14 years, 5 months

2
1
0 0

risu instruction set test harness now publicly available

by Peter Maydell

Hi. As part of my work on qemu I've written a simplistic random instruction sequence generator and test harness. To quote the README: risu is a tool intended to assist in testing the implementation of models of the ARM architecture such as qemu and valgrind. In particular it restricts itself to considering the parts of the architecture visible from Linux userspace, so it can be used to test programs which only implement userspace, like valgrind and qemu's linux-user mode. I don't particularly expect this tool to be of much general interest outside people developing either qemu or valgrind or similar models, but I have in any case made it publicly available now: http://git.linaro.org/gitweb?p=people/pmaydell/risu.git;a=tree -- PMM

14 years, 5 months

2
3
0 0

RFC: Dynamic hwcaps

by Dave Martin

Hi all, I'd be interested in people's views on the following idea-- feel free to ignore if it doesn't interest you. For power-management purposes, it's useful to be able to turn off functional blocks on the SoC. For on-SoC peripherals, this can be managed through the driver framework in the kernel, but for functional blocks of the CPU itself which are used by instruction set extensions, such as NEON or other media accelerators, it would be interesting if processes could adapt to these units appearing and disappearing at runtime. This would mean that user processes would need to select dynamically between different implementations of accelerated functionality at runtime. This allows for more active power management of such functional blocks: if the CPU is not fully loaded, you can turn them off -- the kernel can spot when there is significant idle time and do this. If the CPU becomes fully loaded, applications which have soft-realtime constraints can notice this and switch to their accelerated code (which will cause the kernel to switch the functional unit(s) on). Or, the kernel can react to increasing CPU load by speculatively turn it on instead. This is analogous to the behaviour of other power governors in the system. Non-aware applications will still work seamlessly -- these may simply run accelerated code if the hardware supports it, causing the kernel to turn the affected functional block(s) on. In order for this to work, some dynamic status information would need to be visible to each user process, and polled each time a function with a dynamically switchable choice of implementations gets called. You probably don't need to worry about race conditions either-- if the process accidentally tries to use a turned-off feature, you will take a fault which gives the kernel the chance to turn the feature back on. Generally, this should be a rare occurrence. The dynamic feature status information should ideally be per-CPU global, though we could have a separate copy per thread, at the cost of more memory. It can't be system-global, since different CPUs may have a different set of functional blocks active at any one time -- for this reason, the information can't be stored in an existing mapping such as the vectors page. Conversely, existing mechanisms such sysfs probably involve too much overhead to be polled every time you call copy_pixmap() or whatever. Alternatively, each thread could register a userspace buffer (a single word is probably adequate) into which the CPU pokes the hardware status flags each time it returns to userspace, if the hardware status has changed or if the thread has been migrated. Either of the above approaches could be prototyped as an mmap'able driver, though this may not be the best approach in the long run. Does anyone have a view on whether this is a worthwhile idea, or what the best approach would be? Cheers ---Dave

14 years, 5 months

7
17
0 0

[ACTIVITY] November 29th-December 5th

by Julian Brown

== Linaro GCC == * Worked on quad-word/big-endian fixes patch. Sent off a version on Tuesday which worked OK, but which made some awkward changes to the middle-end. Tried to re-think those parts, but without much luck: came to the conclusion that spending more time trying to fix element-ordering-dependent operations on quad-word vectors in big-endian mode was probably not worth the effort (since we plan to be changing things in that area anyway). Wrote a much-simplified patch which simply disables those patterns, and ported it to mainline. * Then, spent some time trying to set up big-endian testing with a mainline build, since the lack of such an option is partly why we got into this mess to start with. My current plan (as well as testing the above patch) is to create an upstreamable patch to easily enable big-endian (Linux) multilibs, in the hope that it'll generally make big-endian testing easier. (Of course people will still need test harness configurations which will allow running big & little-endian code, which most won't have.) * Also, ping lp675347 (volatile bitfields vs. QT atomics), and do some some extra checks suggested by DJ Delorie, which seemed to work out fine. Backported patch for lp629671 to Linaro 4.4 branch, and ran tests (also fine). * Continued discussion of internal representations for fancy vector loads/stores in GIMPLE/RTL on linaro-toolchain.

14 years, 5 months

1
0
0 0

[ACTIVITY] Nov. 19 -- Dec. 05

by Zach Welch

== Last Week == * Continued implementing support for ARM unwind tables in libunwind. * Sent patches upstream to improve binutils's readelf, adding support for all remaining unwind table instructions (i.e. VFP/NEON and WMMX). When used on ARMv7a, provides meaningful output for previously 'unsupported' opcodes that get used in some libraries (e.g. glibc). == This Week == * Continue working on libunwind. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

14 years, 5 months

1
0
0 0

[ACTIVITY] Nov 29 - Dec 3

by Ulrich Weigand

== GDB == * Posted updated implementation of #661253 (Improve backtrace by using ARM exception tables) to gdb-patches, which includes several changes requested by reviewers * Posted updated patch to further improve backtrace (in the absence of debug info) to gdb-patches * Commented on a couple of GDB LP bugs == Miscellaneous == * Started setting up IGEP v2 board 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

1
0
0 0

qemu linux-user mode issues

by Peter Maydell

Since it came up in the toolchain meeting this morning, some links to issues people are having doing ARM scratchbox-style builds because of generic linux-user issues: http://bugs.meego.com/show_bug.cgi?id=10529 # linux-user's mmap implementation isn't very smart https://bugs.launchpad.net/qemu/+bug/668799 # qemu locking issues which can cause build failures (sometimes) -- PMM

14 years, 5 months

1
0
0 0

[ACTIVITY] week 48

by Marcin Juszkiewicz

https://blueprints.launchpad.net/ubuntu/+spec/other-linaro-n-cross-compilers: - wrote patches for creating backports PPA - each component [1] generates versioned -source binary package (eglibc-2.12.1-source etc) - a-c-t-b [2] got "PPA" boolean variable in rules to have one source package for archive and for backports - I built a-c-t-b with all components backports from natty in lucid pbuilder Bugs: - 684625 - libc6 is compiled for armv5 instead of armv7a - confirmed, wrote fix, will sent for review and merge - 683832 - gcc fails to cross compile Qt - confirmed in maverick for cross gcc 4.4/4.5 - need to check with fixed (bug 684625) toolchain - FTFBS of armel-cross-toolchain-base 1.53/natty - issue is lack of LTO plugin built in gcc/stage2 - have first patches for it, need to test 1. component = eglibc, gcc-4.4/4.5, binutils, linux 2. a-c-t-b = armel-cross-toolchain-base Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

14 years, 5 months

1
0
0 0

[ACTIVITY] Nov.29 -- Dec.05

by Chung-Lin Tang

== GCC related == * PR44557, Thumb-1 ICE: originally thought a fix of constraint will work, however after simplifying the testcase, received another ICE in postreload, due to a load of IP, which is not permitted in Thumb-1. Looking at some reload internals as part of fixing this. * PR45416, ARM code generation regression. First fix from last week hit an assert FAIL in the alias-oracle due to ARRAY_REFs not being handled there. Also, further found some expand code quality regressions due to this change. Turned to a more conservative fix by adding the related TER substitution to expr.c:do_store_flag(), which produced more focused results. However, 32-bit x86 slightly regressed in the same flag storing code (did not use the 'testl' insn after the change). Still WIP. * PR46667, submitted a section type conflict bug fix upstream, see http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00137.html , which supposedly fixes the upstream ARM-Linux C++ build. Jan Hubicka later gave another fix, so still in discussion. * PR45886, this PR is call for backporting the __ARM_PCS* preprocessor symbols to gcc-4_5-branch. Submitted a mail to ask for approval, no response. == libffi VFP hard-float == * PR46508, libffi VFP assembly error. I missed this earlier due to using a compiler configured with --with-fpu=vfp. Submitted assembly fix to add the needed FPU directives. Committed to upstream trunk. == This week == * Hope to wrap up the above in-progress PRs, as well as continue to look at other PRs of interest. * LP #685534 popped up on Sunday, and manifests on upstream trunk too. Add this to queue. * Think about GCC performance opportunities (Linaro)

14 years, 5 months

1
0
0 0

[ACTIVITY] Nov 29th -- Dec 5

by Yao Qi

== Linaro GCC == * Reproduce regression of my ldm/stm backport on 4.5, which is caused by the other two merged patches in ifcvt.c. Fix them. Propose merge request again. Learn how to sync/merge changes from one branch to the other branch. * Fix VFP_D0_D7 handling in predicate vfp_register_operand. Approved and committed upstreams. * Test new regrename improvement patch on x86_64, and measure effectiveness of it on ARM. Code size of bash-3.2 is reduced 0.2% with option "-march=armv7a -mthumb -O2 -frename-registers". Eric B. is almost OK with this patch except some wording in comments. == Linaro GDB == As discussed in UDS, I'll move to GDB work for gdb correctness. http://ex.seabright.co.nz/helpers/planner#tr-toolchain-gdb-correctness In this month, I'll focus on GDB testsuite failures fixing. * Analyze LP:615978, failures in gdb.base/annota3.exp. Signal is not delivered to child while software single-stepping. The same as LP:649121. * Fix failure in gdb.xml/tdesc-regs.exp. LP:685494 It is caused by a target triplet matching error, when target is set to "armv7l-linux-gnueabi". Target triplet matching in test cases should be changed. Patch is being reviewed in upstreams. * LP:616000 failures caused by -fstack-protector. Homework to understand frame-related code in GDB. Got some big picture of usage of some key data structures inside GDB on frame. Compared with prologue with and without stack-protector, find some difference there. Still no clue on how to educate GDB to identify whether stack-protector is turned on or off. * Fix one failure in printcmds.exp. LP:685702 This test case on 7.2 branch is a little bit out of date, compared with GDB trunk. Backport one patch on trunk to 7.2 branch can fix this problem. Backport patch is being reviewed in upstreams. * Neon registers in kernel dump file. LP:615972 Ask Linaro kernel WG to see how to move forward on this. Discussion is still ongoing. == This Week == * Report the rest of GDB testsuite failures. * Pick up some of them, and fix. * Pass gcc patches in my queue one by one to gcc-patches to review. -- Yao (齐尧)

14 years, 5 months

1
0
0 0

[ACTIVITY] report week 48

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: ** Nathan Froyd (CodeSourcery) has reviewed a lot of my ARM patches. Most were OK, one or two needed tweaking We seem to have come to agreement on how best to treat the API between qemu and the softfloat library, and I have a V2 patchset ready to mail as soon as Nathan has commented on the final patch. ** posted a patch to rename a very misleading _is_nan() function ** identified list of correctness patches in meego and samsung trees and issues noted within ARM ** qemu: posted patch to remove an unused function ** started looking at the first patch in the meego tree, which fixes VQSHL. I have already discovered a bug in this insn not covered by the meego patch... Meetings: toolchain, PD update, ARM 20th birthday party Plans: - qemu consolidation Issues: * Locking in qemu is definitely insufficient, especially (but not exclusively) when running multi-threaded programs in linux-user mode. https://bugs.launchpad.net/qemu/+bug/668799 has an example problem and some discussion; I'm hoping some other qemu developers have an opinion, but the nicest approach IMHO would involve fairly invasive changes to how qemu implements interrupting a cpu which is executing TCG code. Not sure where this should sit in the priority list. Things of note: - there has been some discussion of broadening the "KVM Forum" conference to include other virtualisation related topics including Xen and also the TCG aspects of Qemu. Still all up in the air but possibly colocated with LinuxCon in Vancouver in August. See: http://www.linux-kvm.org/page/KVM_Forum_2011 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, 5 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Looked at a generic bug in GAS's handling of ifuncs. Sent a patch upstream: http://sourceware.org/ml/binutils/2010-11/msg00495.html Alan quite reasonably wanted me to test on a variety of targets. For want of anything better, I wrote a script to test Alan's list of 118 targets. Tests went OK, patch committed upstream. * Wrote more IFUNC tests. Found another problem (as yet unresolved). * Looked at vector stuff, but nothing tangible yet. (I also had to spend some time on other IBM things, sorry.) == Next week == * Away Monday and Tuesday. * More STT_GNU_IFUNC and vectors. Richard

14 years, 5 months

1
0
0 0

[ACTIVITY] 2010-12-03

by David Gilbert

* Benchmarking of simple package builds with various string routine versions; not finding enough difference in the noise to make any large conclusions * Looking at the string routine behaviour with perf to see where the time is going - getting hit by the Linaro kernels on silverbell missing Perf enablement in the config - Useful amount of time does seem to be spent outside the main 'fast aligned' chunks of code - pushing/popping registers does seem to be pretty expensive * Started looking at libffi and hard float - Started writing a spec https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/LibFFI-variadic - It's going to need an API change to libffi, although the change shouldn't break any existing code on existing platforms where they work. * Helping with the image testing Dave

14 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain