- linaro-toolchain - lists.linaro.org

[Activity] 2011-03-04 week 9

by Ramana Radhakrishnan

Starting back in Linaro land after a gap of 3-4 weeks where I've been away on ARM internal tasks. == GCC == - Setting up a new machine that I received for Linaro work. - Spent some time reviewing upstream patches. Spent some time on the P1 PR47719 upstream to get this fixed . - Starting to read up on the benchmarking report and recreating the environments. - Looked through some of the speed tickets to have a look through and spend some time on it. - Put in a hardware request for a Panda board. == Next Week == - Set up environment properly for some amount of benchmarking. - Look at some of the performance regressions and work on some things that need to be done. - Continue looking at PR47719.

14 years, 6 months

1
0
0 0

[ACTIVITY] 2011-03-04

by David Gilbert

* Investigated and fixed sqlite3 testsuite failure on ARM (bug 725052) * Discussing libffi API changes with maintainer; hopefully he's going to send out his comments today. * Looking at how to upstream the string routine changes * Need to look at big endian testing * Testing QEmu pre-release for Peter; looking very nice. Dave

14 years, 6 months

1
0
0 0

[ACTIVITY] report week 09

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | 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 | == maintain-beagle-models == * preparation and test for next week's qemu-linaro 2011-03 release * put in a temporary fix for bug 723630 (apt/glibc now try prlimit64 syscall, so silence qemu warnings about not implementing it) * investigated qemu warnings about bad 16 bit writes: this is a kernel bug: https://bugs.launchpad.net/linux-linaro/+bug/727781 == vexpress model == * sent vexpress patches upstream, put into qemu-linaro == merge-correctness-fixes == * more work on performance counter registers: proper cycle counter implementation; now just needs a bit of tidying before upstreaming * ran valgrind's test cases on qemu; added revealed issues to https://blueprints.launchpad.net/qemu-linaro/+spec/merge-correctness-fixes * sent patch fixing broken VMOV s0,s1,r0,r1 implementation * sent patch fixing inverted carry bit on ORNS == other == * meetings: toolchain, standup, architecture q&a, pdsw-tools, team brief 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, 6 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Submitted the fix for the Qt miscompilation upstream. Applied after approval. * Submitted a patch for the Thumb LDR problem that Dave Martin hit. This was rejected. * Ended up spending a few days on the "unreasonable amount of memory while compiling qemu" bug due to unfamiilarity with the DWARF 2 code. I realise the original idea was that I'd just file this upstream, but it was one of those cases where I kept finding out more info for the bug report until the problem became obvious. I've now submitted two patches for this upstream. The first was trivial and is now in. I was asked to add a bit of extra code to the second, which I hope to do next week. * Looked at the MIPS bug that was reported against the Linaro toolchain. This turned out to be a problem in our extension elimination pass. Submitted a merge request for that. * Got confirmation from ARM that we should use relocation number 160 for R_ARM_IRELATIVE, and that it was OK to make the changes public (thanks!). I've now submitted the binutils patches upstream. I'll do the eglibc ones when I get back. == Next week == Holiday! Richard

14 years, 6 months

1
0
0 0

[ACTIVITY] February 27- March 3

by Revital1 Eres

Hello, Testing the patch for SMS to support targets that their doloop part is not decoupled from the rest of the loop's instructions, as SMS currently requires. The testing includes bootstrapping on ARM machines for c language configured w and w\o --with-arch=armv7-a options and using"-O2 -fmodulo-sched -fmodulo-sched-allow-regmoves -fno-auto-inc-dec -funsafe-math-optimizations -mthumb" flags. Thanks, Revital

14 years, 6 months

1
0
0 0

GCC PR43137

by Andrew Stubbs

On Monday, I was asked to find out whether the fix for GCC Bugzilla PR43137 was present in our source base. I can confirm that it is *not* present. Apologies for the delay. Andrew

14 years, 6 months

1
0
0 0

What configuration(s) to test?

by Andrew Stubbs

Hi All, Up until now, I have had no choice but to test toolchain correctness on A8 hardware. It made sense to use the same -mfpu settings as the Linaro/Ubuntu package builds use. This did not match the policy that the interesting platform was A9-NEON, but I didn't have that option. That's changed now - our Panda boards have arrived! Yay! :) But, it seems to me that if I change to using the Pandas for correctness testing (not performance testing) then I won't be testing what Ubuntu will actually use. So what should I test on? I'd rather not double my test load by testing on both, but that is an option .... Any suggestions? Andrew

14 years, 6 months

2
1
0 0

Re: Thumb-2 kernel on imx51/efikamx

by Dave Martin

Hi, On Mon, Feb 28, 2011 at 9:19 PM, Nicolas Pitre <nicolas.pitre(a)linaro.org> wrote: > On Thu, 24 Feb 2011, John Rigby wrote: > >> The resulting kernel builds and boots but some modules have problems: >> >> $ modprobe fat >> fat: unknown relocation: 102 >> FATAL: Error inserting vfat > > A workaround for what appears to be a binutils bug has been merged in > linaro-2.6.38. So the Thumb2 kernel testing may resume on trusted > targets. Thanks for merging it. It's a bit ugly to include turn off compiler optimisations to work around this though, so we might encounter upstream to that patch. In any case, we still need someone to take a look at the possible tools issue -- CC'ing linaro-toolchain in case people aren't aware: https://bugs.launchpad.net/binutils-linaro/+bug/725126 Cheers ---Dave

14 years, 6 months

2
1
0 0

Re: [RFC] Linaro Toolchain for Android and NDK

by Jim Huang

On 25 February 2011 22:28, Alexander Sack <asac(a)linaro.org> wrote: > On Wed, Feb 23, 2011 at 8:28 AM, Jim Huang <jserv(a)0xlab.org> wrote: >> I would like to make a proposal about utilizing Linaro toolchain for >> Android and NDK (Native Development Kit)[1]. Added linaro-toolchai list in Cc. >> ** Motivation >> >> There are some different perspectives between Linaro toolchain and >> Google Android toolchain including technical and >> non-technical considerations. It doesn't really work if we only >> replace prebuilt toolchain with Linaro toolchain because >> of the compatibility of Android system utilities such as ELF >> prelinker. Also, since Android is developed in relatively closed > > I don't have enough background to understand this "ELF prelinker" > stuff. Are you saying that because of the way how android links stuff > we cannot have one code base for gcc that works for both, android and > "normal libc linux"? > Take Bug #707487 for example: https://bugs.launchpad.net/binutils-linaro/+bug/707487 It is evident that Android's system utilities like soslim ("strip" implementation) and apriori ("prelink" implementation) expect the specific output of GNU Toolchain, but it sometimes varies since we would take Linaro's toolchain. >> environment (Google style open source model), a great amount of >> software components are not always verified by different >> toolchain or build configurations. This proposal attempts to > > ack. thats what we want to do. Of course, we cannot really verify what > is going on behind closed walls, but we can continuously build android > with our toolchain and fix issues due that in android public master > and if even that doesn't work we can ensure that our android trees > always work nicely with both, our gcc and android gcc. > Android team is known to work on this field already. > Another thing is to make our toolchain easily consumable (like the NDK > you mention at the bottom); this will increase chances that someone > from google can eventually take a look at what we are doing etc. and > also helps the community to use linaro toolchain to built their > android distributions. Agree. >> establish the compact development flow to enable Linaro >> optimized ARM toolchain to build Android from scratch and verify it >> transparently. Eventually, Android can be the reference >> indicator as Linaro toolchain performance and reliability. >> >> >> ** Brief introduction to Google Android toolchain >> >> Inside Google, there is a dedicated compiler team working on GNU >> Toolchain for various purposes including server-side >> computing, Android, Chrome OS, etc. Google engineers submit patches to >> upstream for public review and maintain the >> toolchain for Android. Along with each Android Open Source Prokect >> (AOSP) release, there is a special branch in korg >> GIT [2] for hosting the GPL'd toolchain source code modified by >> Google. Usually, file "README.google" mentioned the >> summary, but it is not developer friendly because several changes were >> done within one GIT commit. >> >> Please refer to wiki for details: >> https://wiki.linaro.org/Platform/Android/UpstreamToolchain >> > > thats a good wiki page. thanks for the content. If I read the skia > example correctly, we could add a test to our "normal" abrek testsuite > that uses our daily android toolchain and run the skia benchmark? e.g. > we could start doing this benchmarking even without having a > validation solution ready for android targets? > If adb is supposed to work well on target, then you can easily use "bench.py" script mentioned in the above wiki to do several benchmarking. > Please let's talk to Paul how we can get the android toolchain to > /opt/android as part of abrek and lets try to add this to our abrek > testsuites. Until we have daily toolchain builds it would be OK to > download the android toolchain tarball from a fixed place from > people.linaro.org I guess. > Ok! >> ** What's wrong with Android upstream Toolchain? >> >> In my opinion, list as following: >> >> (1) Few information about Google improvement: Sometimes, we have to >> guess something from implicit GIT commitlog >> such as "commit gcc-4.4.3 which is used to build gcc-4.4.3 Android >> toolchain in master"[3]. It is hard to track and get >> verified carefully. > > yes, that feels like a messy situation. Do we know why they don't > commit the changes as individual commits but then in next step > document what they changed? I have no exact idea since I am just an observer regarding Android's GIT tree. Google engineers do send patches to FSF/GNU, but it is not always related to the GIT activities we have seen in korg. You can search the keyword, "submit", in file gcc/gcc-4.4.3/README.google , and you will see some descriptions as following: gcc/cp/cp-lang.c gcc/gimple.c gcc/langhooks-def.h gcc/langhooks.h gcc/langhooks.c gcc/tree-flow.h gcc/tree-ssa-dce.c gcc/testsuite/g++.dg/tree-ssa/vptr_init_dse.C gcc/testsuite/g++.dg/tree-ssa/vptr_init_dse2.C Enhancing dead code elimination to eliminate useless vptr field initialization. Owner: davidxl Status: not submitted gcc/fold-const.c gcc/Makefile.in Fix 2045297 Owner: davidxl Status: Not submitted The information is too few to track for us since the above "Fix 2045297" tends to indicate Google bug database number instead of FSF's. >> (2) Google specific improvements are absent in recent release, only >> enabled months later. For example, Google Compiler >> Team Lead, Dr. Shih-wei Liao, presented the improvements against GNU >> Toolchain in the middle of 2009.[4]. The report >> came with several impressive improvements like FDO (Feedback Directed >> Optimizations) and IPO (Inter-Procedure >> Optimizations). However, only some of them are public to AOSP and be >> integrated late in the middle of 2010 (Android >> Froyo; 2.2). Even FDO was merged in Android Froyo already, but there >> is few documentation and no robust method to verify >> by community members such as Linaro engineers. > > you say that they don't publish the code for lets say the > "gingerbread" toolchain in a timely fashion when they release > gingerbread? Or do they ship a separate "fast" NDK/prebuilt for > partners through secret channels? I have no idea. >> (3) For some reasons, Google tends to deliver stable (old) toolchain >> plus mainline backport. It is a safe and workable approach, >> but sometimes developers would expect to use the latest technologies >> as Linaro aims to bring to the world. >> >> (4) Few readable documentation. For example, Google already open its >> toolchain benchmark suite in early 2010, but there was >> no document specific to such important components. Furthermore, there >> was one file gone in public kog GIT, required by >> automated benchmark process. One year later, Google engineer finally >> put back the one to public. This implies the unusual way >> Google developed and delivered software. >> > > Assuming good faith I would think this might just have been an oversight. > > Do you know if anyone from community pointed this out to google using > official android mailing lists/groups or a bug? > Google engineers sometimes pick up the issues from Google Code: http://code.google.com/p/android/issues/list And, they do discuss on mailing-list: http://developer.android.com/community/ >> ** Linaro's Approach to enable latest technologies >> >> Linaro android team tries to do: >> (1) Document Android toolchain and related utilities in korg GIT as >> possible as we can. > > That's good stuff and I think your wiki page is already a great > contribution in that direction. What we should do though is run this > through google eyes early by using official android mailing lists. > Got it. >> (2) Early adaptation of Linaro toolchain to Android build system and >> verify these output systematically. > > ack. Do you know if those changes would be conflicting with what we do > on "normal" linux side? e.g. do we need to maintain special android > patches or can we merge those into our main trees? > In fact, GCC 4.6 already merges Android specific patches with the help of CodeSourcery. We would initially backport these patches to linaro-gcc-4.5 branch for review. Luse Cheng already did it. However, other parts are not related to Android directly, and they might be too aggressive to generic GCC optimization, that can be the reason why Google didn't submit first. >> (3) Backport Google changes to Linaro GCC and review in public. > > This is really tricky as you said. Here again, we should propose this > on android mailing lists to maybe get feedback from google team and > maybe improve the way we work on that. Untangling a big patch based > just on changelog feels really unefficient. Ok, I got your point. However, what we need is to create workable combination of Linaro kernel + Linaro toolchain for Android integration engineers. Alexander, I need your help to catch the attention of someone at Google. > Also, we have to remember that if we pick changes out of _their_ tree, > we cannot upstream those to fsf because we don't own copyright to > those. Of course, for stuff they already pushed to 4.6 its not a > problem to backport them from fsf trunk. Thanks for notice. >> (4) Improve the deployment and validation flow by means of Linaro >> infrastructure. > > my understanding is this: > > 1. we add support to build android toolchain from linaro branches to > our cloud build service > 2. we do this so that we either produce a full toolchain tarball that > can be installed under /opt/android or a NDK tarball (or both) NDK doesn't need admin permission to install. > 3. we improve our android platform build infrastructure to allow > using latest daily toolchain tarball and then we build android with a) > google toolchain and b) linaro toolchain; in this way we get daily > android builds for both toolchains that can go into the linaro > validation farm and get the typical validation/testing and > benchmarking done. Yes, it would be great. >> (5) Build and test Android system with Linaro tools. Then, figure out >> the regressions caused by Linaro Toolchain and/or >> aggressive optimizations > > right. I think that's covered with the point above, no? The android > builds done with our toolchain would also be available in public, so > you can do whatever you want on top of what we already > test/validate/measure automatically in the validation farm with them. Agree. >> (6) measure performance gain by Linaro tools > > right. for this we need to define a set of open-source benchmarks to > run and ensure that those are supported in our validation framework. > >> The detailed specification in wiki: >> https://wiki.linaro.org/Platform/Android/Specs/LinaroAndroidToolchain >> >> ** Implementation of Linaro toolchain for Android >> >> We started from Android style toolchain build and move to Linaro GCC + >> ARM specific optimizations in mind. The initial work >> can be obtained by wiki: >> https://wiki.linaro.org/Platform/Android/Toolchain >> >> We plan to maintain the following GIT repositories at least: >> * android/toolchain/build.git : Linaro-aware build system. Derived >> from Android toolchain build system, it can handle Linaro-GCC >> and Linaro snapshot/bzr. >> * android/toolchain/gcc-patches.git : Patchset to be applied on top >> of Linaro-GCC release/snapshots > > I think thats fine. however, how do we ensure that we have patches > that always apply to both release/snapshots? do we maintain branches > for gcc-patches.git in case you need two versions of patch X if the > linaro gcc codebase diverged? I might need help from toolchain WG. >> The reference builder script output: >> $ ./linaro-build.sh --help >> --prefix-dir= Specify where to install (default: >> /tmp/android-toolchain-eabi) >> --gcc-src-dir= Specify where linaro gcc source is (in <toolchain>/gcc) >> --apply-gcc-patch=(yes|no) Apply-patch which in >> <toolchain>/gcc-patches directory (default: no) >> >> Current verified combinations: >> * gcc-linaro: 4.5-2011.02-0 >> * binutils: 2.20.1 >> * gmp: 4.2.4 >> * mpfr: 2.4.1 >> >> Only gcc is replaced by gcc-linaro: 4.5-2011.02-0 and others are >> checked out from korg GIT. > > do we need to do something like --gcc-src-dir and -patches for > binutils, gmp and mpfr as well? or would we be only interested in > improving/fixing gcc for now? > I think focusing on linaro-gcc is pretty good. We can follow the original combination of Google. > Waybe we also want to support protocol schemes like git: http: and > bzr+ssh:/lp: for the --gcc-src= argument. this would then > automatically download/branch the source tree from the given location. > What do you think? Agree. >> ** Summary of gcc-patches >> >> "gcc-patches" are used as "backport" from Google changes into Linaro >> gcc base. Here is the summary at present: >> >> 0001-Add-linux-android.patch >> Add linux-android >> >> 0002-Add-support-for-Bionic-C-library.patch >> Add support for Bionic C library >> >> 0003-Support-compilation-for-Android-platform.patch >> Support compilation for Android platform >> >> 0004-Add-multilib-configuration-for-arm-linux-androideabi.patch >> Add multilib configuration for arm-linux-androideabi >> >> 0005-Fix-gthr-posix.h-to-support-Bionic.patch >> Fix gthr-posix.h to support Bionic >> >> 0006-Add-untested-support-for-Bionic-to-libstdc.patch >> Add [untested] support for Bionic to libstdc++ >> >> These patches are taken from Maxim Kuvyrkov of CodeSourcery in gcc-4.6 >> branch. Of course, we can always add changes by >> Google or other Android specific adaptation by this model. > > Can we get a toolchain example tarball done and uploaded to > people.linaro.org? I would like to verify that those work out of the > box with gingerbread and if so, i would like to see those land in the > main toolchain WG branch rather than adding them to our gcc-patches > tree. Yes, I would like to do that later. >> ** Planned improvements over Linaro toolchain for Android >> >> (1) GCC multilib setting >> Default: arm, fpu and thumb. The prebuilt google toolchain use: >> armv5te and mandroid. We should focus on ARMv7. >> (2) HardFP-ABI Support for Android. >> (3) Patch management: Better to get the Android patches into >> Linaro-GCC tree eventually. >> (4) Build system improvement. Don't have to build gmp, mpfr everytime, >> and provide option to build without gdb. >> (5) Enable LTO (Link Time Optimization, introduced since gcc-4.5) in >> Android TARGET_GLOBAL_CFLAGS >> (6) Verify the functionality of FDO (Feedback Directed Optimization) >> and introduce the approaches to integrate. > > I really think those topics should be executed by the toolchain WG > rather than in platform. I am happy that we give them guidance and > support them by providing them with easy to use tools to get their job > done. Also feeding them with topics is great. Please talk to Michael > Hope and ask him how he wants to collect those android toolchain > optimization topic ideas. Could be good input for our 11.11 > requirements gathering process. Agree. >> ** Toward Android NDK >> >> Once Linaro toolchain for Android is ready to use, it is time to >> re-package Android NDK by Linaro toolchain. To do that, extra >> build configuration, sysroot, is required. According to Android >> Release Cycle & Phases[5], the repacked NDK should be verified >> one moth after Android public release. > > That sounds like a great idea. What's the a benefit/difference of > shipping an NDK compared to just shipping a "normal" toolchain binary > tarball for this purpose? NDK consists of some architecture specific helper scripts/headers to indicate the optimization flags and some combinations such as ARMv7 with/without NEON, etc. If we provide NDK directly, users don't have to consider the above integration issues as far as I know. Sincerely, Jim Huang (jserv) Android Team

14 years, 6 months

2
2
0 0

[ACTIVITY] 21st - 26th February

by Andrew Stubbs

Temporarily took over Tech Lead of the Toolchain Working Group while Michael Hope recovers from the Christchurch earthquake. (He's fine, but unable to work.) This didn't actually require any action, in the end. Michael returned to work towards the end of the week. Forward ported, benchmarked, and posted one of Mark Shinwell's NEON patches upstream. Further benchmarking was not possible as the Panda board I was using is located in Christchurch, NZ. Merged and tested the FSF GCC 4.5 branch into Linaro GCC. There were a couple of test regressions in the fortran testsuite, so I've filed bug lp:723086. The other test results were either the same or better. Benchmarked the ARM A8 function/jump alignment patch to see what effect it has in GCC 4.6. Found no measurable improvement in EEMBC. I suggest dropping this patch. Brought the patch tracker up-to-date, and entered tracking tickets for all outstanding patches. Merged FSF trunk to Linaro GCC 4.6. Committed Jie's Thumb2 testcase fix to FSF GCC trunk. Thanks to Ramana for using his new found authority to approve it. Investigated the suitability of several of the patches for forward-porting. Corresponded with Benrd and Julian. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

14 years, 6 months

1
0
0 0

[ACTIVITY] Feb 21 -- Feb 27

by Chung-Lin Tang

== Last week == * Launchpad #721021 GCC ICE on ARM/XScale: identified as case of upstream PR45177; backported and pushed to Linaro. * Launchpad #709453/CS Issue #7122: Neon vmov 0.0 issues; some progress on my current WIP patch, but tests showed another 3 regressions, still on-going. * Launchpad #711819/GCC PR47719: ICE in push_minipool_fix. Ramana reminded that my patch, which added some pool range attributes, were actually removed earlier by Bernd in the fix for PR43137. Discussed and mostly concluded that we should add them back for now. Will re-submit patch with testcase to gcc-patches this week. * Coremark ARMv7-A regressions: still work in progress. == This week == * TW Public Holiday Feb.28 (Mon). * Ping some of my upstream patch submissions. * Get incompleted issues done. * Coremark regression investigation.

14 years, 6 months

1
0
0 0

GCC M4 DSP support

by Christian ANDERSSON2

Hello Linaro toolchain guys, I have a few questions regarding GCC fully supporting the ARM Cortex M4, I'm especially thinking of the additional DSP instructions and if these are supported and how optimal the code being produced is? Thanks for your support, Best Regards Christian (ST-Ericsson)

14 years, 6 months

2
1
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == Investigate developer tools == * Finished latrace investigation. == PandaBoard == * The defective PandaBoard that was sent back in December is now repaired and on my desk again. It doesn't show the behaviour of #708883 and works flawlessly so far. :) == libunwind == * Did some debugging of the test-async-sig testcase to get started with libunwind. It will dead-lock if you add "--enable-debug" since libunwind does printfs in this case which are not signal safe. * Sorted out which of Zachs patches are upstream and which are not. * Started to learn about the different unwind methods that libunwind provides on ARM. Regards Ken

14 years, 6 months

1
0
0 0

[ACTIVITY] 2011-02-25

by David Gilbert

== ffi == * Sent variadic patch for libffi to libffi-discuss * Worked through some suggestions from Chung-Lin, need to do some rework == string routines == * memchr & strchr patch sent for inclusion in ubuntu packages * tried sqlite's benchmarks - they don't spend too much time in the C library; although a few % in memcpy, and ~1% in memset (also seem to have found an sqlite test case failure on ARM and filed as bug 725052) == porting jam == * There wasn't much traffic on #linaro during this related to the jam * I closed bug 635850 (fastdep FTBFS) which was already fixed with an explicit fix for ARM in the changelog and bug 492336 (eglibc's tst-eintr1 failing) which seems to work now but it's not clear when it was fixed. * Looking at eglibc's test log there seem to be a bunch of others that are failing and may well be worth investigating. * bug 372121 (qemu/xargs stack/number of arguments limit) seems to work ok, however the reporter did say it was quite a fragile test; that needs more investigation to see whether the original reason has actually been fixed. == misc == * swapping notes with Peter on the PBX SD card investigation Dave

14 years, 6 months

1
0
0 0

[ACTIVITY] report week 08

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | 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 | == maintain-beagle-models == * rebased qemu-linaro on upstream * checked omap_uart model for any issues with enabling the extended (non-16550A) features which the new Linux drivers need. Sent meego merge request for patchset which turns on the features, and does a little cleanup. Now in meego, qemu-linaro. == merge-correctness-fixes == * reviewed versions 5 and 6 of Christophe's vrecpe/vsqrte patchset; v6 was good and has now been committed * sent a version of "dummy cp14 debug registers" patch upstream; however I've realised it triggers a false positive in the temp-leak debugging code in target-arm/translate.c * wrote/sent a patch which moves this temp-leak debugging code into TCG proper (which I think makes it much simpler and cleaner and avoids the false positives mentioned above) * some work on the cp15 performance counter registers. I now have some code which I think is a fully architecturally valid implementation of an "implements no events" core, except that we don't implement the cycle count register. * started testing/review of Adam's VA-to-PA translation regs patch. In the course of this discovered that qemu unconditionally implements an ARM940 cp15 WFI register which clashes with these; submitted patch to add correct not-for-v6/v7 feature gating. * sent out patch fixing usermode seeks by 32 bit guest on 64 bit host (based on a diagnosis and suggested fix by Eoghan Sherry) * sent patch fixing compile error in vnc code == vexpress model == * sent a patchset for fixing the MMC card detect wiring on PBX upstream; this is needed for vexpress too * finished vexpress cleanup and cross-checking against the docs; I now have a patchset I'm happy to upstream and will post next week == other == * took part in pgp keysigning event with emdebian folks * meetings: toolchain, PDSW-tools 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, 6 months

1
0
0 0

[ACTIVITY] Feb 21 - Feb 25

by Ulrich Weigand

== GDB == * Worked with Will Deacon and the Linaro kernel team to make sure HW watchpoint and Versatile Express errata fixes are included in the upcoming Linaro kernel release. * Committed GDB HW watchpoint patches to mainline, and backport to Linaro GDB. This completes work on the HW watchpoint blueprint. * Worked on fixing the GDB part of #620611 (Unable to backtrace out of vector page 0xffff0000). Posted (two versions of) mainline patch for discussion. * Worked on kernel patch for #615974 (Interrupted system call handling). 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

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Looked at the poor code generated for Neon load/store intrinsics. Looked into the history behind the treatment of VFP registers by CANNOT_CHANGE_MODE_CLASS. Peter confirmed that the restrictions apply only to VFPv1. Wrote a patch to improve the code, which partly overlapped with Julian's. * Looked at how the operations should be represented at the tree level. Experimented with various combinations of tree codes and types to see which felt right. Wrote this up in the message I sent today. == Next week == * More vectorisation. * Submit some queued patches. * Maybe some bug fixing. (I see there's a reload bug just waiting to be claimed by a lucky developer.) On holiday the following week. Richard

14 years, 6 months

1
0
0 0

Re: Unavailable for a bit

by Michael Hope

Services at ex.seabright.co.nz are back up. On Tue, Feb 22, 2011 at 10:06 PM, Michael Hope <michael.hope(a)linaro.org> wrote: > Hi there. We've had an earthquake. Family and friends are fine but i'll be > unavailable for a few days. Services on ex.seabright.co.nz are down. I'll > cancel Wednesdays standup call. > > See you soon, > > -- Michael

14 years, 6 months

1
0
0 0

[ACTIVITY] February 20-24

by Revital1 Eres

Hello, Implemented a patch for SMS to support targets that their doloop part is not decoupled from the rest of the loop's instructions (which is the current assumption of SMS). ARM is an example of such target, where the loop's instructions might use CC reg which is used in the doloop part. Now testing the patch on ARM and other targets that have do-loop. Thanks, Revital

14 years, 6 months

1
0
0 0

[ACTIVITY] February 20-24

by Ira Rosen

Hi, * vectorizer cost model - implemented builtin_vectorization_cost for NEON - added register spilling considerations to the cost model - started testing/tuning on EEMBC Telecom and DenBench (for now I have only two examples for spilling: fdct_int32 mp4encode that shouldn't get vectorized and viterbi that should) * measured vectorization impact on Telecom autcor - it's about 5x (initially I got run time segfault, but the bug is already fixed on GCC trunk, I'll have to check gcc-linaro-4.5 as well) * NEON-vs.non-NEON degradation - started to look at aes. There are 6 loops that get vectorized with 4.6 (due to this patch http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01927.html that allows cond_expr in number of loop iterations expressions) and vzip/vuzp patch, but not with gcc-linaro-4.5. But it doesn't explain the degradation of course. - I don't understand mp4decodepsnr improvement, since I don't see any loops or basic blocks vectorized. Ira

14 years, 6 months

1
0
0 0

Weekly Activity report

by Mounir Bsaibes

Please find the compilation of the weekly activity reports at the following link, if I have missed anyone let me know. https://wiki.linaro.org/WorkingGroups/ToolChain/ActivityReports/2011-02-18 In your report please try to stick to the following format, to help make the report consistant: == Topic == * item 1 * items 2 See https://wiki.linaro.org/Process/Reporting Thanks & Regards, Mounir

14 years, 6 months

1
0
0 0

Improving the code generated for vld and vst intrinsics

by Richard Sandiford

One of the vectorisation discussions from last year was about the poor code GCC generates for vld{2,3,4}_*() and vst{2,3,4}_*(). It forces the result of the loads onto the stack, then loads the individual pieces from there. It does the same thing in reverse for stores. I think there are two major problems here: 1. The result of the vld*() is a record type such as: typedef struct int16x4x3_t { int16x4_t val[3]; } int16x4x3_t; Ideally, we'd like one of these structures to be stored in a pseudo register. However, the ARM port currently limits in-register record types to 64 bits, so something this big is always given BLKmode and stored on the stack. A simple "fix" for this is to increase MAX_FIXED_MODE_SIZE. That would do the right thing for the structures in arm_neon.h, but wouldn't be safe in general. 2. The vld*() returns values as a single integer (such as EI mode), while uses of the value will typically be in a vector mode such as V4SI. CANNOT_CHANGE_MODE_CLASS doesn't allow direct "mode-punning" between the two in VFP_REGS, so this again forces the punning to be done on the stack. The code in question is: /* FPA registers can't do subreg as all values are reformatted to internal precision. VFP registers may only be accessed in the mode they were set. */ #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ ? reg_classes_intersect_p (FPA_REGS, (CLASS)) \ || reg_classes_intersect_p (VFP_REGS, (CLASS)) \ However, the VFP restriction appears to be specific to VFPv1 -- thanks to Peter for the archaeology -- and isn't a problem for v6+. In that case, removing this restriction is an important optimisation. I tried the patch below on the following simple testcase: #include "arm_neon.h" void foo (uint16_t *a) { uint16x4x3_t x, y; x = vld3_u16 (a); y = vld3_u16 (a + 12); x.val[0] = vadd_u16 (x.val[0], y.val[0]); x.val[1] = vadd_u16 (x.val[1], y.val[1]); x.val[2] = vadd_u16 (x.val[2], y.val[2]); vst3_u16 (a, x); } (not necessarily sensible!). Before the patch, -O2 produced: sub sp, sp, #48 add r3, r0, #24 vld3.16 {d16-d18}, [r3] vld3.16 {d20-d22}, [r0] add r3, sp, #24 vstmia sp, {d20-d22} vstmia r3, {d16-d18} fldd d19, [sp, #8] fldd d16, [sp, #0] fldd d17, [sp, #24] fldd d20, [sp, #32] vadd.i16 d18, d16, d17 vadd.i16 d17, d19, d20 fldd d19, [sp, #16] fldd d20, [sp, #40] vadd.i16 d16, d19, d20 fstd d18, [sp, #0] fstd d17, [sp, #8] fstd d16, [sp, #16] vldmia sp, {d16-d18} vst3.16 {d16-d18}, [r0] add sp, sp, #48 bx lr After the patch we get: vld3.16 {d24-d26}, [r0] add r3, r0, #24 vld3.16 {d20-d22}, [r3] vmov q8, q12 @ ti vadd.i16 d17, d17, d21 vadd.i16 d16, d24, d20 vadd.i16 d18, d26, d22 vst3.16 {d16-d18}, [r0] bx lr The VMOV is a bit disappointing, and needs further investigation. The first hunk fixes (2), and I think is correct. The second hunk hacks (1), and isn't suitable in itself. I'll next try to make arm_neon.h use built-in record types that are explicitly EImode, which should remove the need to change MAX_FIXED_MODE_SIZE. Richard Index: gcc/gcc/config/arm/arm.h =================================================================== --- gcc.orig/gcc/config/arm/arm.h +++ gcc/gcc/config/arm/arm.h @@ -1171,10 +1171,12 @@ enum reg_class /* FPA registers can't do subreg as all values are reformatted to internal precision. VFP registers may only be accessed in the mode they were set. */ -#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ - (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ - ? reg_classes_intersect_p (FPA_REGS, (CLASS)) \ - || reg_classes_intersect_p (VFP_REGS, (CLASS)) \ 2+#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ + (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ + ? (reg_classes_intersect_p (FPA_REGS, (CLASS)) \ + || (TARGET_VFP \ + && reg_classes_intersect_p (VFP_REGS, (CLASS)) \ + && arm_fpu_desc->rev == 1)) \ : 0) /* The class value for index registers, and the one for base regs. */ @@ -2458,4 +2460,6 @@ enum arm_builtins instruction. */ #define MAX_LDM_STM_OPS 4 +#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (XImode) + #endif /* ! GCC_ARM_H */

14 years, 6 months

2
4
0 0

Unavailable for a bit

by Michael Hope

Hi there. We've had an earthquake. Family and friends are fine but i'll be unavailable for a few days. Services on ex.seabright.co.nz are down. I'll cancel Wednesdays standup call. See you soon, -- Michael

14 years, 6 months

2
1
0 0

[ACTIVITY] Feb 14 - Feb 17

by Ulrich Weigand

== GDB == * Working with Will Deacon, identified root cause of GDB problems running on Versatile Express in SMP mode, and verified that Errata workaround fixes the problem * Finished testing GDB HW watchpoints patch on vexpress, submitted complete patch set for mainline inclusion * Reviewed Yao's mainline patch to enable displaced stepping in Thumb mode 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

2
3
0 0

[ACTIVITY] Feb 14 -- Feb 20

by Chung-Lin Tang

== Last week == * PR46178, PR46002: both upstream issues related to the priority coloring mode of IRA. Both patches submitted, the first already approved and committed. Vladimir M. did mention that the priority algorithm would be removed once his newer "cover class-less" patches goes in during stage1. Anyways, I got more familiar with IRA during the process, and the patches will still be applicable to 4.5/4.6. * PR43872: incorrectly aligned VLAs under ARM. This turned out to be a one-liner fix. Submitted upstream awaiting approval. * Discussed on email/IRC with Revital Eres on SMS and ARM doloop pattern issues. * Launchpad #721021: Linaro GCC ICE under -mtune=xscale. Investigated a bit; did not see ICE immediately, but GCC went into infinite loop (Khem Raj, the reporter, says it runs for a while then ICEs). * Coremark ARMv5TE vs ARMv7-A performance regression: reproduced consistently using our own Tegra boards. Investigated and seem to have found something, will post more detailed findings later. == This week == * Coremark investigation. * More GCC issues.

14 years, 6 months

1
0
0 0

Continuous build results

by Michael Hope

Hi there. I've created a new mailing list for the automated build results of Linaro GCC, Linaro GDB, and (once-weekly) FSF 4.5 and 4.6. You can subscribe by going to: https://launchpad.net/~linaro-toolchain-builds I've subscribed everyone in the toolchain working group. If you'd like to get these emails, go to: https://launchpad.net/people/+me/+editemails and set 'Linaro Toolchain Builds' to 'Preferred address'. Any build failures will also go to linaro-toolchain(a)l.linaro.org. The archive is here: https://lists.launchpad.net/linaro-toolchain-builds/ You can also track the crude state of the build hosts here: http://ex.seabright.co.nz/helpers/scheduler and see things status scroll by on #linaro-cbuild on Freenode. This was kicked off due to the problems with the 2011.01 release. The follow-up is tracked here: https://blueprints.launchpad.net/gcc-linaro/+spec/incident-followup-1 -- Michael

14 years, 6 months

2
2
0 0

[ACTIVITY] 14th - 19th February

by Andrew Stubbs

== GCC == Posted 2 of our 4.5 patches upstream. My latest 4.6 build and test completed, so I've pushed an update to the bzr branch. The branch is now up to mainline state as of the 12th. Merged 3 4.5 patches into Linaro GCC 4.6. Upstream review isn't happening, so I've decided to commit them anyway. The last upload (FSF mainline as of 12th Feb) will therefore become the baseline I'm going to use for Linaro GCC 4.6. Begun benchmarking the questionable patches before forward porting them, using EEMBC. Michael Hope has given me access to one of his A9 Panda boards in New Zealand. This ought to have been straight-forward, but of course it wasn't. It took me a while to convince myself I was getting meaningful results and testing the right thing. Also the A9 seemed to be able to complete the configured iterations in 'zero' time, which fooled me for a while. I think I now have a set up that works. It seems to run very slowly sometimes though - something to do with SSH? ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html * Jie's thumb2 testcase fix: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00670.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html

14 years, 6 months

1
0
0 0

[ACTIVITY] report week 07

by Peter Maydell

RAG: Red: Amber: Green: DATE/QEMU conference place confirmed, travel booked Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | 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 | * maintain-beagle-models: + implemented missing epoll syscalls for qemu usermode, submitted upstream https://bugs.launchpad.net/qemu-linaro/+bug/644961 + tracked down the problem causing serial console to break: the new Linux driver uses some extra features of the UART which we weren't modelling https://bugs.launchpad.net/qemu-linaro/+bug/714600 * merge-correctness-fixes: + reworked VZIP/VUZP patch as per review comments, resubmitted + reviewed CL's latest shift patches, added fixes of my own for large shift counts and overlapping src/dest regs, submitted a 10 patch rolled up series + reviewed a patch for adding cp15 VA-PA translation ops + reviewed various versions of vrecpe/vsqrte patches from CL * versatile-express model: B Labs kindly made available their Versatile Express board model: https://github.com/bbalban/qemu/commits/universal-branch and I've spent a few days getting it to boot a Linaro kernel, fixing a few bugs and cleaning up the patchset in preparation for upstreaming it. This included discovering a bug in qemu's SD card model which was causing Linux not to be able to detect cards on PL181, and resulting in spurious qemu warnings on omap3: https://bugs.launchpad.net/qemu-linaro/+bug/714606 * other: + ARM architecture Q&A for modelling engineers + booked travel/hotel for QEMU conference * meetings: toolchain, PDSW-tools, PD comms, Linaro-in-ARM network infrastructure, pdsw-doughnuts and 1st birthday celebration, 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, 6 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * continued to look into latrace and found an issue in case a dynamic library gets unloaded. Otherwise latrace looks quite good on ARM. https://wiki.linaro.org/KenWerner/Sandbox/latrace * chasing bugs: - After a lot of testing Andy Green has made a big step forward in finding the root cause for the shut-down issue of my PandaBoard. The PMIC is seeing an overcurrent and issues an interrupt that gets ignored by current kernels. Then the PMIC shuts the board down for safety reasons. As a workaround Andy has made a kernel patch for the twl6030 driver that enables all interrupt sources. The kernel will acknowledge the overcurrent reported by the PMIC and the board survives. A patched kernel binary can be found at: https://wiki.linaro.org/KenWerner/Sandbox/708883 - While testing Andys patches on the linaro natty kernels I ran into https://bugs.launchpad.net/bugs/720055 - The flash-kernel utility doesn't work on the PandaBoard because the subarch check expects omap4 instead of omap: https://bugs.launchpad.net/bugs/721147 - Looked into the apr fail (process shared mutex's fail on armel v7). Their mutex functionality can be mappped to various methods, but only pthread is of interest here. The code relies on pthread_mutex_lock and pthread_mutex_trylock which is implemented by the (e)glibc. The c library uses GCCs __sync primitives if eglibc >= 2.12.1-0ubuntu11 and GCC >=4.5. The testprocmutex testcase passes now. https://bugs.launchpad.net/bugs/604753 Regards Ken

14 years, 6 months

1
0
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

"Will Deacon" <will.deacon(a)arm.com> wrote on 02/16/2011 01:07:09 PM: > > I've now built a kernel with CONFIG_ARM_ERRATA_720789 enabled, and the > > symptoms indeed seem to have disappeared completely ... > > Yup - that's because without it, invalidating a TLB entry for a particular > process isn't broadcast correctly, so you can end up using the old (pre-COW) > mappings if you're running on a different core. OK. So I guess the only remaining questions is: if this hardware needs the errata fix to work properly, shouldn't it be automatically selected by the kernel configure logic? Note that this appears to happen for certain OMAP boards, see arch/arm/mach-omap2/Kconfig: config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC select PL310_ERRATA_588369 select ARM_ERRATA_720789 <<===== select USB_ARCH_HAS_EHCI But this does not happen for the vexpress; arch/arm/mach-vexpress/Kconfig has only: config ARCH_VEXPRESS_CA9X4 bool "Versatile Express Cortex-A9x4 tile" select CPU_V7 select ARM_GIC 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

2
1
0 0

[ACTIVITY] February 13-17

by Revital1 Eres

Hello, * Continue looking into DENbench benchmarks. * While testing SMS I realized that my current implementation of doloop pattern for ARM does not follow SMS's requirement to have the doloop instructions be decoupled from the other loop's instructions. This happens because doloop uses CC register which might be used elsewhere in the loop. I am looking into a solution for that. Thanks, Revital

14 years, 6 months

1
0
0 0

[ACTIVITY] February 13-17

by Ira Rosen

Hi, This week I looked into DENBench: * sad8_c (hot function from mp4encode) needs SLP reduction, but it also contains cond_expr which cannot be vectorized as reduction, so I don't think there is anything I can do here * fdct_int32 (another hot function from mp4encode) now gets vectorized with vzip/vuzp patch, but the vectorization causes performance degradation here because of multiple register spills. I also noticed that vectorizer costs are not set for NEON, i.e., it uses default costs. So, I am now working on costs for NEON and adding registers consideration into vectorizer's cost model. I also did some general vectorization research, checking opportunities of collaboration with GRAPHITE pass and auto-parallelization. Ira

14 years, 6 months

1
0
0 0

Summary of required work for a Versatile Express QEMU model

by Peter Maydell

I mentioned in the toolchain standup call that I'd done a quick estimate of the work required to support vexpress, so I thought I might as well clean it up a little and post it. This is a quick summary and time estimate for adding Versatile Express support to qemu. The general idea is that most of the components on this board already have QEMU implementations (since they're standard ARM primecells used in versatile/realview), and we can live without the few major components that aren't implemented (maybe we'd need dummy implementations if the kernel prods them on startup.) Components already supported by QEMU: ------------------------------------- A9MPx4 PL050 keyboard, mouse SMCS LAN9118 ethernet PL011 UARTs SP804 timers Components with a near match in QEMU: ------------------------------------- PL111 CLCD -- qemu has a PL110 PL180 MMC card -- qemu has a PL181 -- both cases should either just work or be fairly trivial tweaks Components not supported by QEMU: --------------------------------- PL041 audio compact flash two-wire serial bus (for PCI-express switch config and DVI-I displays) ISP1761 Philips USB controller User switches and LEDs -- vexpress specific, but trivial to do Components where a dummy implementation should be sufficient: ------------------------------------------------------------- PL310 L2 cache controller PL341 dynamic memory controller PL354 static memory bus controller trustzone controllers Other required work: -------------------- The usual knitting for interrupts, clocks, reset etc etc. Summary ------- Assuming we're happy not to worry about support for audio, USB, two-wire serial bus or compact flash, this is about two weeks work to put together, test and get a more-or-less upstreamable patchset from. This would produce a platform hopefully at least as usable as versatile, but with an A9 and 1GB RAM. -- PMM

14 years, 6 months

3
6
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

"Will Deacon" <will.deacon(a)arm.com> wrote on 02/14/2011 11:30:45 AM: > > - In testing on Versatile Express, I noticed what appears to be SMP > > related bugs in handling regular software breakpoints: occasionally, > > software breakpoints simply are not hit and execution continues as if > > the underlying code had not been changed at all. This symptom > > completely goes away if GDB and the debugged process are forced to > > the same CPU using the affinity feature (e.g. with schedtool). > > I've seen this issue in the past but I thought I'd fixed it. What kernel are > you using and do you have CONFIG_ARM_ERRATA_720789 enabled? I'm using the 2.6.37-1002-linaro-vexpress kernel from the Linaro package of the same name. This does *not* have CONFIG_ARM_ERRATA_720789 enabled (presumably because the mach-vexpress/Kconfig file does not add it?) ... > > My guess, just from seeing those symptoms, would be that when inserting > > a software breakpoint via ptrace, not all i-caches on all CPUs are > > reliably flushed ... Any thoughts on this? > > There was an I-cache aliasing problem in the kernel coupled with a TLB > invalidation hardware bug on the versatile express. I fixed these though > and haven't seen any problems since. Hmm, a TLB flush problem could also explain the symptom (because the write of the breakpoint to the text section causes a copy-on-write operation which installs a new page ...) I'll try rebuilding the kernel with the above config option enabled. > Hmmm, I'll need to have a think about this. What does GDB do if it receives > a SIGTRAP with si_addr set to (potentially) complete nonsense? As an aside, > Cortex-A15 reports the faulting address for a watchpoint correctly, so we > will be able to use multiple watchpoints there. The GDB common core can handle either of the following two indications: A) The (read/write/access) watchpoint at address XXX triggered. B) A write watchpoint may have triggered at some address. In the case of B, GDB will scan all the write breakpoints it is currently tracking and compare the current value at that address with the last value it remembers being present there. Any changes GDB sees will cause it to report the corresponding watchpoint as triggered. As far as the kernel interface is concerned, the important issue that the ARM native target in GDB is able to understand what the kernel reports, so it can in turn report either case A or B to the common core. This means as long as there is some way for GDB to understand the kernel is reporting a write watchpoint hit at an unknown address, everything is fine. This could be done e.g. be reporting a "slot" zero in si_errno to indicate the slot (and then also the address) triggering the watchpoint is unknown ... > > - Finally, I noticed when reading kernel code that under some > > circumstances, the kernel will automatically do a single step to > > get off a watchpoint that was just hit. However, this does not > > happen for user-space watchpoints installed via ptrace, right? > > (Just wanting to confirm; since GDB currently does that single > > step itself -- we don't want *both* kernel and GDB to issue a > > single step each ...) > > If the {break,watch}point has been inserted via ptrace, the kernel will > send a SIGTRAP instead of stepping the instruction. OK, thanks for the confirmation! > > I haven't gotten to looking further into other hardware (IGEP, > > Panda) -- that's next on the list. > > Good stuff, keep me posted if you see any further problems! Sure, will do! 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

2
2
0 0

Announcing the Linaro porting jam

by Steve Langasek

Hello, my fellow ARM aficionados! The Linaro Developer Platform Team is pleased to announce a new initiative to help improve the state of software on ARM: the ARM porting jam. Starting today, February 16th, we will be running a weekly IRC jam on Wednesdays from 1400-1800 UTC to bring developers together to work on all manner of userspace porting bugs, with the aim of fixing portability issues and getting the fixes delivered to our upstreams. An initial porting queue of known issues can be found here: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue Interested in making the software in Ubuntu run better on ARM? Stop on by the #linaro channel on irc.linaro.org today! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

14 years, 6 months

1
0
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

"Will Deacon" <will.deacon(a)arm.com> wrote on 02/11/2011 10:13:01 AM: > I don't have a pandaboard, so I'd be interested to see if the code > works there. I developed it using ARM boards, so the versatile express > is a known good target. I've now got it working reliably on on Versatile Express, after fixing a couple of bugs on the GDB side (both in the HW-watchpoint patch, and in common GDB code). The testsuite now passes with no regressions when enabling HW watchpoints, except for two tests that require more than one single watchpoint to be supported. This raises another couple of issues/questions, however: - In testing on Versatile Express, I noticed what appears to be SMP related bugs in handling regular software breakpoints: occasionally, software breakpoints simply are not hit and execution continues as if the underlying code had not been changed at all. This symptom completely goes away if GDB and the debugged process are forced to the same CPU using the affinity feature (e.g. with schedtool). My guess, just from seeing those symptoms, would be that when inserting a software breakpoint via ptrace, not all i-caches on all CPUs are reliably flushed ... Any thoughts on this? - As mentioned above, the kernel currently only supports one single watchpoint to be active at a time, even though hardware might support multiple ones. The reason seems to be that when a watchpoint triggers, the kernel cannot figure out which one it was (if there's more than one choice). This is a bit unfortunate, given that GDB will attempt to insert two or more watchpoints in many interesting cases (e.g. a "watch *p" command will insert *two* low-level watchpoints, one at the address of p, and one at the address where p (currently) points to). In addition, for regular (write) watchpoints, GDB does not actually *require* the underlying hardware/kernel to specify which watchpoint was hit; GDB is able to find out by itself by checking whether the values at any of the currently active locations actually changed. (For read/access type watchpoints, GDB does require that underlying support -- but those are much more rarely used anyway.) Do you see any chance of improving upon the current behaviour? - Finally, I noticed when reading kernel code that under some circumstances, the kernel will automatically do a single step to get off a watchpoint that was just hit. However, this does not happen for user-space watchpoints installed via ptrace, right? (Just wanting to confirm; since GDB currently does that single step itself -- we don't want *both* kernel and GDB to issue a single step each ...) I haven't gotten to looking further into other hardware (IGEP, Panda) -- that's next on the list. 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, 7 months

2
1
0 0

[ACTIVITY] 7th - 12th February 2011

by Andrew Stubbs

== Linaro GCC 4.5 == Re merged all the patches I've had to back out of Linaro GCC due to various test failures. I've now found all the extra fixes/patches necessary to make them go ... I think. Tested the build and test on ARM and x86_64. == Linaro GCC 4.6 == Continued getting the 4.5 patches forward ported to 4.6. I now have about 4 patches waiting for review upatream, or ready to be posted. Upstream review isn't happening though. This partly due to GCC being in stage 4, but mostly due to Richard Earshaw being on sabatical, and the other maintainers being inactive. I can see that I'm going to have to abandon my hopes of only merging to Linaro GCC once it's been approved upstream, and be content with merging to Linaro once it's posted upstream. Started another test to rebase the Linaro 4.6 branch with the latest from upstream. Once that's done, I think I'll start merging my changes in, and call that our baseline. (There'll still be merges from upstream, but the history will diverge.) ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html * Jie's thumb2 testcase fix: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00670.html

14 years, 7 months

1
0
0 0

[ACTIVITY] Jan 31 -- Feb 13

by Chung-Lin Tang

== Week of Jan.31st--Feb.6th == * Vacation, Chinese New Year Holiday. == Last week == * Monday (Feb.7th), last day of vacation. * LP #711819, ICE in push_minipool_fix: this turned out to be a simple case where a memory load alternative was not tagged with the minipool range attributes. Patch sent upstream, awaiting approval. * LP #709453, wrong code generated for NEON. Tracked this down and mostly know how to fix this, but discussion with Ramana brought the issue up that the entire idea of using NEON vmov.i32 for loading VFP constants may not be good for A9, and unclear for A8. We probably should just revert the patch from the Linaro tree for now. * PR46002, IRA internal compiler error with -fira-algorithm=priority. Been looking at this as a part of my background IRA studies. Have a possible patch for this, plus found another assert fail ICE under ARM. Will see if can post upstream this week. == This week == * Continue to look at above unfinished issues, as well as other new ones.

14 years, 7 months

1
0
0 0

[ACTIVITY] Jan 07 - Feb 11

by Ulrich Weigand

== GDB == * Installed 2.6.37 Linaro kernel on IGEP and Versatile Express in order to verify support for HW breakpoints/watchpoints * Tested GDB HW watchpoints patch, fixed several bugs in the patch and core GDB, and got it working reliably on vexpress * Started discussion with Will Deacon (ARM) regarding possible further enhancements to related kernel support 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, 7 months

1
0
0 0

[ACTIVITY] 2011-02-11

by David Gilbert

== String routines == * Copied an improvement I'd previously made to memchr (removing a branch using a big IT block) to strlen * Modified benchmark setup to build everything as a library to fairly give everything a PLT overhead. * Pushed optimised memchr and strlen and simple strchr into cortex-strings bzr repo * Patched eglibc to use memchr and strchr code - although currently fighting to get appropriate .changes file == ffi == * Kicked off TSC request for license permissions == bugs == * Built and recreated the qt4-x11 bug, produced all the dumps and boiled it down to a few lines of suspicious RTL for Richard. ** Away next week.

14 years, 7 months

1
0
0 0

[Activity] Jan 31 - Feb 8th

by Ramana Radhakrishnan

== GCC == * Finished testing fix for lp:709329 and got that merged. * Wrote up a plan for GCC performance improvements based on what we discussed at the sprint. * Internal ARM tasks that kept me busy for most of last week and this week. Plans: * still stuck on some ARM internal tasks for next week.

14 years, 7 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Got the STT_GNU_IFUNC work ready to submit. Split out some preparatory patches, including fixes for some general ARM inefficiencies that I noticed this week. Ran the EGLIBC testsuite (including ifunc tests) and they passed. * Discussed ideas for representing permuted vector loads with Ira. I'm still um-ing and ah-ing about the various possible approaches, but I think I understand the constraints a bit more now. * Fixed Qt miscompilation (lp #705689). * Fixed PC-relative load bug in the assembler (lp #716967). == Next week == Holiday! Richard

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 06

by Peter Maydell

RAG: Red: Amber: DATE/QEMU conference still hasn't confirmed I have a place... Green: qemu-linaro first release made! Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | * maintain-beagle-models: + first qemu-linaro release (2011.02-0) made on time + fixed OMAP3 MMC controller model bug that was causing the kernel to hang when enabling a swapfile; pushed fix to qemu and meego trees + rebased qemu-linaro on new upstream * merge-correctness-fixes + reviewed some softfloat patches from Christophe; testing of the half-precision floating point conversion instructions showed up a number of other bugs which I submitted patches for: http://patchwork.ozlabs.org/patch/82594/ (n/6) + reviewed and tested Christophe's patches for VQMOVUN and VSLI.64/VSRI.64; these have been committed upstream + fix compile failure if !CONFIG_USE_GUEST_BASE http://patchwork.ozlabs.org/patch/82630/ + remove stray #include halfway through source file http://patchwork.ozlabs.org/patch/82661/ + improved vmull.p8 implementation over the meego version, sent upstream: http://patchwork.ozlabs.org/patch/82657/ + upstreamed patch to fix VQDMLSL: http://patchwork.ozlabs.org/patch/82752/ + upstreamed patch fixing thumb-to-arm neon dp insn conversion: http://patchwork.ozlabs.org/patch/82757/ + upstreamed patches fixing Neon VZIP and VUZP * other + did a quick estimate of required effort to do vexpress model (answer: 2 weeks if we don't want audio/USB/compact flash) + usual crop of standing meetings 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, 7 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * moved from Ubuntu Maverick to Natty on the PandaBoard * investigation on the LTTng User Space Tracer: https://wiki.linaro.org/KenWerner/Sandbox/LTTng * started to look into latrace: https://wiki.linaro.org/KenWerner/Sandbox/latrace The idea is neat but there are issues in case the users code does dlclose on a shared object. I'll investigate further when time permits. * spent some time on IBM internal process work Regards Ken

14 years, 7 months

1
0
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

Hi Will, > > - It seems odd that the kernel says it doesn't support the debug > > architecture, but then reports to user space that 1 watchpoint and 6 > > breakpoints are supported ... GDB will never use the watchpoint, because > > the maximum watchpoint size is reported as zero, but GDB will attempt to > > use the breakpoints. Setting a breakpoint will appear to succeed, but then > > the breakpoint just never triggers. The kernel should IMO be more > > consistent in how unsupported configurations are handled ... > > Agreed. This is an artifact of how the ptrace info register is populated. > I'll work on a fix tomorrow so that we don't report any resources when > the architecture is unsupported. Great, thanks! > > - Why is architecture 0x4 not supported? This seems to be the variant of > > the v7 debug architecture with memory-mapped registers. Apparently the > > IGEP only supports this version ... Do you know what the > > Beagle-/Pandaboard and other clones do? What would it take to support this > > architecture variant? Given the widespread use of those boards, it would > > be really nice if we could support hardware debugging on them ... > > The memory-mapped interface is hugely unreliable in real hardware because > you have to calculate the address of the memory-mapped debug registers by > using a base and offset, which are hardcoded in some information registers. > Unfortunately, I've never found a board where these registers have been > programmed correctly so (a) I had nothing to test my code with (b) few people > would be able to use it and (c) there's not really a safe way to go around > poking random areas of memory. Huh, I see. I have no idea whether those information registers contain correct values on IGEP .. > > - Which hardware *is* supported? Can you recommend a board I should be > > using to verify GDB support is working? > > The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. > The A5 should work (untested) and the A15 will need a bit of hacking to > get it supported. OK. I guess I can try on our Versatile Express. > > Thanks for your help in getting this working! > > No problem. If you find anybody with working memory-mapped debug and some > spare time, I'd be happy to review patches :) Thanks! I'll try and see if I can figure out where the MM area is on the IGEP ... 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, 7 months

3
2
0 0

[ACTIVITY] February 6-10

by Revital1 Eres

Hello, * Analyzing DENBench benchmarks. * Running mp3 player on Crotex A9 with gcc-linaro -r99463 using SMS flags (*) gives 21% improvement in execution time compared to using only base flags(**). (*) -fmodulo-sched -fmodulo-sched-allow-regmoves (**) -mcpu=cortex-a9 -mtune=cortex-a9 -mthumb -static --fast-math Thanks, Revital

14 years, 7 months

1
0
0 0

[ACTIVITY] February 6-10

by Ira Rosen

Hi, * regtested vzip/vuzp patch * looked into big-endian build * applied all the required patches and checked that Viterbi gets vectorized giving ~2x performance improvement (compiled with cross-compiler) * looked into vld/vst implementation - mostly discussions with Richard * DenBench analysis: - there are loops that should get vectorized with vzip/vuzp patch, I'll check them next week - sad8_c (hot function from mp4encode) needs reduction SLP (which I implemented several weeks ago), and an ability to jump unknown stride in loop SLP - I am looking into this Ira

14 years, 7 months

1
0
0 0

Re: Problems with kernel support for hardware watchpoints

by Arnd Bergmann

On Wednesday 09 February 2011 20:25:32 Will Deacon wrote: > > - Why is architecture 0x4 not supported? This seems to be the variant of > > the v7 debug architecture with memory-mapped registers. Apparently the > > IGEP only supports this version ... Do you know what the > > Beagle-/Pandaboard and other clones do? What would it take to support this > > architecture variant? Given the widespread use of those boards, it would > > be really nice if we could support hardware debugging on them ... > > The memory-mapped interface is hugely unreliable in real hardware because > you have to calculate the address of the memory-mapped debug registers by > using a base and offset, which are hardcoded in some information registers. > Unfortunately, I've never found a board where these registers have been > programmed correctly so (a) I had nothing to test my code with (b) few people > would be able to use it and (c) there's not really a safe way to go around > poking random areas of memory. So the only problem is that it's board specific? That's something we know how to deal with -- all I/O components have some random board specific address, and we put them in a platform device that is listed in the board file. This should be easy enough to do for another register area, though it means we have to do it separately for each board. > > - Which hardware is supported? Can you recommend a board I should be > > using to verify GDB support is working? > > The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. > The A5 should work (untested) and the A15 will need a bit of hacking to > get it supported. Is that because A8 is memory mapped and A9 uses CP14, or is there another problem with A8? Arnd

14 years, 7 months

2
1
0 0

Problems with kernel support for hardware watchpoints

by Ulrich Weigand

Hello Will, I've been trying to get GDB support for hardware watchpoints/breakpoints going. I've ported Matthew's GDB patch to current mainline, and am running this under a 2.6.37-1002-linaro-omap kernel on an IGEPv2 board. However, something seems to be not quite working: I'm seeing this kernel message on boot: hw-breakpoint: debug architecture 0x4 unsupported. and then at runtime, the result of a PTRACE_GETHBPREGS call for register 0 is 0x04000106: debug architecture: 4 watchpoint size: 0 nr. watchpoints: 1 nr. breakpoints: 6 This leads me to a couple of questions: - It seems odd that the kernel says it doesn't support the debug architecture, but then reports to user space that 1 watchpoint and 6 breakpoints are supported ... GDB will never use the watchpoint, because the maximum watchpoint size is reported as zero, but GDB will attempt to use the breakpoints. Setting a breakpoint will appear to succeed, but then the breakpoint just never triggers. The kernel should IMO be more consistent in how unsupported configurations are handled ... - Why is architecture 0x4 not supported? This seems to be the variant of the v7 debug architecture with memory-mapped registers. Apparently the IGEP only supports this version ... Do you know what the Beagle-/Pandaboard and other clones do? What would it take to support this architecture variant? Given the widespread use of those boards, it would be really nice if we could support hardware debugging on them ... - Which hardware *is* supported? Can you recommend a board I should be using to verify GDB support is working? Thanks for your help in getting this working! 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, 7 months

2
1
0 0

Request for new relocation: R_ARM_IRELATIVE

by Richard Sandiford

Hi, I'm working in the Linaro toolchain team on adding ARM support for GNU indirect functions (STT_GNU_IFUNCs). The indirect function feature requires a new relocation type, which is typically called R_FOO_IRELATIVE. I'd therefore like to propose a new R_ARM_IRELATIVE relocation type for the ARM EABI. This relocation is only used in ET_EXEC and ET_DYN objects. If the object has a PT_DYNAMIC tag, then the relocation may only appear in the DT_REL(A) table; it cannot appear in the DT_JMPREL table. (Note that this is a deliberate divergence from the x86 and x86_64 behaviour, which does allow the IRELATIVE relocation to be used in DT_JMPREL table, but which requires it to be applied at load time, regardless of bind-now vs. lazy semantics. However, the proposed ARM behaviour matches that of other targets like PowerPC.) Static ET_EXEC objects may have R_ARM_IRELATIVE relocations. In this case, the relocations are stored in a relocation table that contains no other type of relocation (not even R_ARM_NONE). The static linker defines two symbols: __rel_iplt_start, which the linker points to the start of this table __rel_iplt_end, which the linker points to the last byte of this table plus one. The two symbols are equal if the executable has no R_ARM_IRELATIVE relocations. It is the executable's responsibility to apply these relocations as appropriate. If the static linker emits a symbol table, then it is not defined whether the linker includes __rel_iplt_start and __rel_iplt_end in that symbol table. The static linker may (or may not) define __rel_iplt_start and __rel_iplt_end in dynamic objects. However, if it does define them, the symbols must refer to part of the DT_REL(A) table, and it is still the dynamic linker's responsibility to apply the relocations. An R_ARM_IRELATIVE relocation applies to all bits of a 4-byte field. There are no alignment restrictions on the field. The relocation value is: call(B(S) + A) where call(X) represents the value of r0 after performing an indirect branch-with-link-and-exchange (BLX) to address X. The dynamic linker must have applied all earlier DT_REL(A) relocations before calling X. It is undefined whether later DT_REL(A) relocations have been applied or not, and X must not make any assumptions about the status of those relocations. If there is an R_ARM_IRELATIVE relocation with symbol S and addend A, then the relocation value: call(B(S) + A) is considered to be a load-time constant. It is possible for an object to have more than one R_ARM_IRELATIVE relocation with the same value of B(S) + A, and in such a case, it is not defined whether the dynamic linker invokes the target function each time, or whether it caches the results of earlier calls. I realise this isn't the cleanest extension in the world. As Alan Modra noted on the binutils list, the choice of __rel_iplt_start and __rel_iplt_end is particularly unfortunate, since the relocations are not specific to "PLTs". However, the GNU extension has been defined this way, so unfortunately there isn't much room for target-specific variation. Thanks, Richard

14 years, 7 months

2
3
0 0

Question about big endian

by Ira Rosen

Hi, I'd like to check vzip/vuzp patch in big endian mode. But when I try to compile with -mbig-endian flag, I get > ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon neon-vtrnu8.c -mbig-endian /home/irar/mainline/bin/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../libgcc_s.so.1: could not read symbols: File in wrong format collect2: ld returned 1 exit status What am I missing? Thanks, Ira

14 years, 7 months

3
6
0 0

Today's standup call

by Michael Hope

Hi there. As discussed on Monday, I've shifted today's standup call an hour earlier to 1700 UTC. See you then! -- Michael

14 years, 7 months

1
0
0 0

Linaro GDB 7.2 2011.02 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.2. Linaro GDB 7.2 2011.02-0 is the third release in the 7.2 series. Based off the latest GDB 7.2, it includes a number of ARM-focused bug fixes and enhancements. Interesting changes include: * Backtracing is more reliable through using the ARM specific exception tables for unwinding * Better supports debugging functions compiled with GCC's -fstack-protector * Multiple testsuite related fixes The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.2-2011.02-0 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- Michael

14 years, 7 months

1
0
0 0

Linaro GCC 4.4 and 4.5 2011.02 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.4 and Linaro GCC 4.5. Linaro GCC 4.5 is the seventh release in the 4.5 series. Based off the latest GCC 4.5.2, it includes many ARM-focused performance improvements and bug fixes. Interesting changes include: * Improved code generation in the __sync primitives * Better modelling of the Cortex-A9 NEON pipeline * Added a performance improvement that converts a tree of ifs into a switchs * Many bug fixes Linaro GCC 4.4 is the seventh release in the 4.4 series. Based off the latest GCC 4.4.5, it is a maintenance release that fixes one fault found with offsets on NEON loads. The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.5-2011.02-0 https://launchpad.net/gcc-linaro/+milestone/4.4-2011.02-0 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro -- Michael

14 years, 7 months

1
0
0 0

Linaro QEMU 2011.02-0 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2011.02-0. Linaro QEMU 2011.02-0 is the first official release of qemu-linaro. Based off upstream qemu, it includes a number of ARM-focused bug fixes and enhancements. - This initial qemu-linaro release includes all the ARM code generation fixes from the qemu-meego tree; these are mainly Neon related - The OMAP3 support from qemu-meego is also included - Various bugs which prevented newer Linaro snapshots from booting on the beagle model have been fixed - Bugs causing linaro-media-create to print warnings about unimplemented syscalls and ioctls have been fixed Known issues: - There is no support for USB keyboard or mouse, so only a serial console is usable (#708703) - Images built with linaro-media-create's --swap_file option will not boot (#713101) The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2011.02 Binary builds of this qemu-linaro release are available for users of Ubuntu. Natty users can find qemu-linaro 2011.02-0 in the Ubuntu archive. Users of Ubuntu 10.04 LTS and Ubuntu 10.10 can find packages in the linaro-maintainers tools ppa: https://launchpad.net/~linaro-maintainers/+archive/tools/ More information on Linaro QEMU is available at: https://launchpad.net/qemu-linaro

14 years, 7 months

1
0
0 0

[ACTIVITY] 31st January - 4th February

by Andrew Stubbs

== Linaro GCC 4.5 == Reviewed, tested and merged all the outstanding patches waiting to go into Linaro GCC 4.5. Michael reported that there was a build failure on i686 and amd64. I attempted to reproduce this but my builds completed successfully - very strange. Eventually I found that I had a corrupted checkout and managed to reproduce the problem - thanks bzr! The problem is in Tom's recent changes to stmt.c, so I informed him and backed out the patches, temporarily. Spun the Linaro GCC 4.4 and 4.5 release tarballs and passed them to Michael Hope for final testing. == GCC 4.6 == Tested a more recent version of GCC 4.6 and pushed it to the bazaar repository. Already out of date by the time testing finished of course, but never mind. The number of test failures is greatly reduced. Started another build/test with an even more up-to-date check-out. Begun work merging the 4.5 patches into 4.6. Pushed 1 patch upstream. Got another ready to go, once I've tested it. == Android == Tried to unpick a large patch I was sent that supposedly added Android support to Linaro GCC 4.5. The patch was suspicious from the start because it had large changes to gcc/ChangeLog that clearly backed out the 4.5.2 release. After comparing it against various sources I concluded that it was a 4.6 snapshot from last May with (at least some of) the Linaro patches forward ported, and the release numbers fudged to look like it was 4.5.2 based. This was not terribly helpful - I can't very well backport that into our 4.5 branch! == Upstream GCC == Upstream patches requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html

14 years, 7 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== Last week == * Backported the fixes for lp693502, lp710623 and lp710652 to linaro 4.6 and linaro 4.5. Tested and sent merge requests. * Wrote several more ifunc tests, and fixed the bugs they showed up. Found that ARM generates unnecessary dynamic relocs against GOT entries, so fixed that as a prerequisite. Improved the tracking of STB_LOCAL ifuncs, so that they're treated more like STB_GLOBAL. * Submitted a request for R_ARM_IRELATIVE to be added to the ARM EABI. == This week == * More ifunc. I'm away next week (14th-18th) Richard

14 years, 7 months

1
0
0 0

Extension elimination pass breaks SPU (Fw: spu gcc-4.5 linaro build failure)

by Ulrich Weigand

Hello, Matthias noticed the following ICE when attempting to build the SPU compiler from the Linaro GCC 4.5 sources: ../../../../src-spu/libgcc/../gcc/libgcc2.c: In function '__fixunssfdi': ../../../../src-spu/libgcc/../gcc/libgcc2.c:1344:1: internal compiler error: in spu_expand_mov, at config/spu/spu.c:4575 It turns out that this is due to the new "extension elimination" pass that was recently added in Linaro GCC, as port from the CodeSourcery compiler. This patch has also been proposed, but not yet included upstream. The problem is that this patch seems to frequently introduce instructions that *set* a sub-word lowpart subreg of a register. Now such instructions, according to the docs, are probably valid RTL, but since the effect of the instruction onto the highpart of the register is deliberately left unspecified, they tend to be very infrequently used. Probably because of this, there seem to be parts of the compiler that simply don't handle such instructions correctly. This has been already noticed in the case of the RTL loop optimizers (see discussion here http://gcc.gnu.org/ml/gcc/2010-11/msg00552.html). The failure in the SPU back-end is another instance of the same problem. SPU needs special code to handle subregs (since a "lowpart" SImode subreg of a DImode register is not actually valid on the SPU, because SImode values live in bytes 0..3 while DImode values live in bytes 0..7 of the otherwise big-endian 16-byte SPU registers), and this code simply aborts when given an assignment to a sub-word lowpart subreg. Now, I guess there's two ways forward: either the outcome of the ongoing discussions on gcc-patches is that it is in fact not a good idea to generate such sets, and the EE pass is subsequently rewritten to avoid them; or else, if those instructions are considered valid, I'll have to extend the SPU move expander to handle them. Thoughts? Matthias, if you need a quick workaround for now, I guess you could disable the new pass for SPU by adding a line "flag_ee = 0;" to spu_override_options. 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, 7 months

6
9
0 0

qemu 2011.02-rc2 test results

by Michael Hope

I've had a go with running the QEMU release candidate. Short story is that it boots to a prompt against the 11.05 alpha2 release so I'm happy. It was a messy road so I've written up my train of though here: https://wiki.linaro.org/MichaelHope/Sandbox/QEMU Note that if you follow the instructions on: https://wiki.linaro.org/Releases/GettingInstallingTesting and turn on a swap file then it halts during boot. -- Michael

14 years, 7 months

3
3
0 0

[ACTIVITY] 2011-02-04

by David Gilbert

== String routines == * After some discussions about IT semantics managed to shave a couple of instructions out of a couple of routines * Got around to trying a suggestion that was made some months ago, that LDM is faster than LDRD on A9's; and indeed it does seem to be in some cases; those cases seem pretty hard to define though - it's no slower than LDRD, so it seems best to avoid LDRD. * Digging around eglibc's build/configure system to see how to add assembler routines to only get used on certain build conditions (i.e. v7 & up) == SPEC == * Compiled lbm -O2 and ran it on our local panda and on Michael's ursa1 - it seems happy (with a drop of swap); so I'd say that confirms the issues I previously had were local to something on canis. That's a bit of a pain since it's the only machine with enough RAM to run the rest of the suite. == Other == * Tested a headless Alpha-2 install on our Beagle C4 - mostly worked * Tested qemu-linaro release on the realview-pbx kernel/nfs setup I had * A simple smoke test for pldw on qemu * Tripped over ltrace not working while trying to profile git's use of memcpy and memcmp; it does some _very_ odd things; it's predominant size of memcpy seems to be 1 byte.

14 years, 7 months

2
1
0 0

OpenOCD support for OMAP4/ PandaBoard

by Nicolas Pitre

I just stumbled across this: http://article.gmane.org/gmane.comp.debugging.openocd.devel/15584 And the mentioned clock issue seems to be fixed here: http://article.gmane.org/gmane.comp.debugging.openocd.devel/15619 This is excellent news, and I think we ought to support this at some point. Nicolas

14 years, 7 months

2
1
0 0

[ACTIVITY] Jan 31 - Feb 04

by Ulrich Weigand

== GDB == * Prepared Linaro GDB 7.2-2011-02.0 release * Committed two patches to implement LP #661253 (Improve backtrace by using ARM exception tables) to mainline and Linaro GDB 7.2 * Provided two follow-on fixes to the patch for LP #616000 (Handle -fstack-protector prologue code); both applied to mainline and Linaro GDB 7.2 * Backported mainline fix for LP #685494 (gdb.xml/tdesc-regs.exp failure) to Linaro GDB 7.2 * Identified root cause of LP #711375 (gdb internal error in inline_frame_this_id trying to debug a qemu target); committed fix to mainline and Linaro GDB 7.2 * Worked on re-implementation of fix for LP #615978 (Failure to software single-step into signal handler) 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, 7 months

1
0
0 0

[ACTIVITY] Week 2011-2-04

by Mounir Bsaibes

=== Toolchain === * Organized the Weekly Release Meeting Status pages https://wiki.linaro.org/WorkingGroups/ToolChain/Status * Organized the collection of weekly Activity https://wiki.linaro.org/WorkingGroups/KernelConsolidation/ActivityReports * Started to track Linaro events planned and approved attendance https://wiki.linaro.org/Internal/People/MounirBsaibes/ToolchainScratchpad(f… now) * Started to monitor bug handling * Reviewed and tracked blueprints status (burdown charts) * Kernel WG various PM tasks * Power Management WG various PM tasks ==== Plan ==== * Continue investigating importing blueprint and WI's data into OpenProj using OpenProj xml file * map bleuprint/WI's fields to the OpenProj xml fields

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 05

by Peter Maydell

RAG: Red: Amber: DATE/QEMU conference still hasn't confirmed I have a place... Green: qemu-linaro RC2 prerelease uploaded Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-02-08 | 2011-02-08 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | * maintain-beagle-models: + RC1 packaging flushed out some bugs: ++ we include some binary blobs which we're better not distributing: https://bugs.launchpad.net/qemu-linaro/+bug/709965 ++ a couple of array overruns don't compile with our picky armel gcc: https://bugs.launchpad.net/qemu-linaro/+bug/709711 https://bugs.launchpad.net/qemu-linaro/+bug/711272 (both fixes sent and applied upstream) ++ we ought to include a fix for the "swp" in qemu-lock.h: http://patchwork.ozlabs.org/patch/81205/ (patch sent upstream, no comment on it yet) + ...so I have rolled an RC2 tarball with these fixed + investigated why USB keyboard model doesn't work: it turns out that the OMAP host USB model is basically just a stub + some warnings from qemu about bad width accesses are a symptom of a nasty disagreement between gcc and the kernel about getting atomic 32 bit accesses: http://www.spinics.net/lists/arm-kernel/msg113002.html + warnings from qemu about access to a nonexistent i2c register appear to be a kernel bug in the i2c driver for OMAP36xx: https://bugs.edge.launchpad.net/linux-linaro/+bug/645324 + investigated a hang running images built with linaro-media-create's --swap_file option. Still digging but I suspect the Linux driver doesn't cope with an MMC card which can erase in zero time... * merge-correctness-fixes + the usual upstream mailing list monitoring and code review + sent patch for PLI and hint space decoding fixes: http://patchwork.ozlabs.org/patch/81711/ * misc + some non-Linaro time this week; may be more next week + some advance planning of what we might want to do with QEMU in the future 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, 7 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * I continued to setup the pandaboad but ran into #708883 - tested vaious various hwpacks and headless images - used different power supplies and several SD cards - built various test kernels from the linux-linaro-natty.git * looked into the crash utility * https://wiki.linaro.org/KenWerner/Sandbox/crash-utility#future%20areas Regards Ken

14 years, 7 months

1
0
0 0

gcc-linaro-4.5+bzr99469 build failure

by Michael Hope

The current revision fails to bootstrap on i686: http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99469/logs/i686-lucid-cbu… libtool: compile: /scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc/xgcc -shared-libgcc -B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc -nostdinc++ -L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src -L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/bin/ -B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/lib/ -isystem /scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/include -isystem /scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-linaro-4.5/libjava -I./include -I./gcj -I../../../gcc-linaro-4.5/libjava -Iinclude -I../../../gcc-linaro-4.5/libjava/include -I../../../gcc-linaro-4.5/libjava/classpath/include -Iclasspath/include -I../../../gcc-linaro-4.5/libjava/classpath/native/fdlibm -I../../../gcc-linaro-4.5/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../gcc-linaro-4.5/libjava/libltdl -I../../../gcc-linaro-4.5/libjava/libltdl -I../../../gcc-linaro-4.5/libjava/.././libjava/../gcc -I../../../gcc-linaro-4.5/libjava/../zlib -I../../../gcc-linaro-4.5/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\" -DTOOLEXECLIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib\" -DJAVA_HOME=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\" -DBOOT_CLASS_PATH=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/libgcj-4.5.2.jar\" -DJAVA_EXT_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.5.2-11/classmap.db\" -g -O2 -D_GNU_SOURCE -MT exception.lo -MD -MP -MF .deps/exception.Tpo -c ../../../gcc-linaro-4.5/libjava/exception.cc -o exception.o >/dev/null 2>&1 ../../../gcc-linaro-4.5/libjava/prims.cc: In function 'jboolean _Jv_isPrimitiveOrDerived(const Utf8Const*)': ../../../gcc-linaro-4.5/libjava/prims.cc:287:5: internal compiler error: in set_jump_prob, at stmt.c:2211 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. The log is available here: http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99469/logs/i686-lucid-… -- Michael

14 years, 7 months

2
4
0 0

do we consider extravagant memory usage a gcc bug?

by Peter Maydell

Trying to build qemu on a beagle board: CC sparc64-linux-user/translate.o cc1: out of memory allocating 26975704 bytes after a total of 70742016 bytes # ls -lh target-sparc/translate.c -rw-r--r-- 1 root root 191K Jan 31 12:05 target-sparc/translate.c ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile. (and probably more overall since the board has 500MB RAM total and it hit the out-of-memory condition). This seems a bit excessive to me, but do we consider it enough of a bug to be worth looking into? (I believe this source file has caused compile failures on the buildds too, which have rather more RAM/swap than my beagle.) -- PMM

14 years, 7 months

4
5
0 0

[ACTIVITY] January 30 - February 3

by Revital1 Eres

Hello, Profiling Denbech: * The profiling information on x86 indicate that some benchmarks might need to run longer as helper functions such as t_run_test are reported to be hot. So I've increased the time each benchmark is executed and will continue to experiment with that for the problematic benchmarks until I start to see more reasonable results. * Opened PR711819 after having an ICE running DENbench with trunk (natively built on ARM machine). - I've started to look at an old patch for SMS that was written in 2005 by colleague; Mostafa Hagog; to place the register moves in free slots. Currently, they are placed greedily before each def thats needs them. Thanks, Revital

14 years, 7 months

1
0
0 0

[ACTIVITY] January 30 - February 3

by Ira Rosen

Hi, I continued to work on vect_interleave and vect_extract implementation on NEON: * debugged the compiler to find out what's the problem with neon_vzip/vuzp<mode>_internal * fixed it following Uli's advice * checked how neon_vzip/vuzp<mode>_internal work for intrinsics by writing tests * fixed the patch according to Uli's comments * now fully testing the patch Thanks, Ira

14 years, 7 months

1
0
0 0

Help with define_insn

by Ira Rosen

Hi, I am trying to implement interleave_high/low and extract_even/odd using vzip and vuzp instructions. I am attaching a patch that attempts to do that. It uses already existing neon_vzip<mode>_internal. The problem with it is that it doesn't express the fact that the two outputs of vzip depend on both inputs, which causes wrong code generation in CSE: for (a,b)<- vzip (c,d) and (e,f) <- vzip (g,d) CSE decides that b==f, since on RTL level b and f depend only on d. Here is neon_vzip<mode>_internal: (define_insn "neon_vzip<mode>_internal" [(set (match_operand:VDQW 0 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")] UNSPEC_VZIP1)) (set (match_operand:VDQW 2 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")] UNSPEC_VZIP2))] "TARGET_NEON" "vzip.<V_sz_elem>\t%<V_reg>0, %<V_reg>2" [(set (attr "neon_type") (if_then_else (ne (symbol_ref "<Is_d_reg>") (const_int 0)) (const_string "neon_bp_simple") (const_string "neon_bp_3cycle")))] ) Is there a way to properly mark the dependence? Thanks, Ira

14 years, 7 months

4
8
0 0

qemu-linaro prerelease available

by Peter Maydell

Hi; this is a note to say that we have now produced a prerelease tarball of qemu-linaro. (The first formal qemu-linaro release will happen in sync with other toolchain group releases on 8th Feb.) This prerelease is primarily to pipeclean the release process and to allow work to start on producing Ubuntu and Linaro packages; however it does include a number of useful bugfixes which are required if you want to be able to boot a recent Linaro snapshot on the beagle model. So the enthusiastic might like to build it from source and give it a spin. Like the Linaro kernel trees, the qemu-linaro tree aims to only include patches we are confident will go upstream; at the moment this means the OMAP3 support and ARM correctness fixes from the qemu-meego tree, based on the qemu upstream trunk. You can download the source tarball from: https://launchpad.net/qemu-linaro/+milestone/2011.02 -- Peter Maydell

14 years, 7 months

1
1
0 0

IT block semantic question

by David Gilbert

Hi, What do people understand to be the expected semantics of IT blocks in the cases below, of which there has been some confusion in relation to a recent Qt issue. The code in question had a sequence something like: comparison IT... EQ blahEQ TEQ BEQ The important bits here are that we have an IT EQ block and two special cases: 1) There is a TEQ in the IT block - are all comparisons in the block allowed and do their effects immediately take effect? As far as I can tell this is allowed and any flag changes are used straight away; 2) There is a BEQ at the end of the IT block, as far as I can tell, as long as the destination of the BEQ is close it shouldn't make any difference if the BEQ is included in the IT block or not. Does that match everyone elses understanding? Dave

14 years, 7 months

2
3
0 0

Generating ancilliary sections with gas

by Dave Martin

Hi all, With gas, does anyone know of a way to create a section whose name is based on that of the current section? The specific requirement is to be able to define a generic macro like the example "fixup" below, whose purpose is to record ancilliary data related to some other section. To illustrate: .macro fixup 100\@ : .pushsection fixup<current section name>, "a" .long 100\@b .popsection .endm .text ... fixup .long sym1 ... .section .other, "ax" ... fixup .long sym2 The linux kernel uses a technique just like this for patching SMP kernels at bootup to work on uniprocessor platforms (when CONFIG_SMP_ON_UP is enabled), resulting in code looking something like this: void exit __attribute__ (( __section__ (".text.exit") )) { ... asm( ... FIXUP("something") ... ); } Note that the inline asm may actually come out of a generic header file rather than being explitly written for this invocation. So it may have to be truly generic. Is far as I have been able to determine, it's not possible to generate sections named based on the current section. In practice, the kernel puts all the fixups into a single section. The downside of this is that when sections are selectively discarded at link time (which in general may happen -- for example, Linux discards the "module exit" code for drivers which are built into the kernel and therefore never exit) there is no way to selectively discard the related fixup entries. Currently the only solution is to include all the module exit code in the image and discard it at run-time when the kernel boots. This is obviously wasteful. Attempting to discard that code at like time results in a link error, since fixups refer to the removed sections. Of course, the "fixup" macro could be given an extra parameter to name the containing section, but the macro can then no longer be called in a generic way: all the calls to that macro must be manually (and buggily) maintained to ensure that the referenced section name is correct, some object post-processing must be done before linking, and/or a tool must be created to implement the missing assembler functionality. Unfortunately, such solutions are likely to be too fragile or complex to make it upstream. It's interesting to note that the same problem will apply for any section containing ancilliary data for another section. In particular, it looks like either the ABI or the assembler has had to grow a special-case workaround for this in order to support exception unwind information sections generated by .fnstart ... .fnend in a sane way: the unwind information sections get called .ARM.ex{idx,tab} for .text, and .ARM.ex{idx,tab}<section> for any other section. As a consequence, link-time discarding can handle this information properly, but IMHO this is a bit of a cheat and admits the general need to create sections with names based transparently on those of other sections, without satisfying that need. .popsection is also an example of such a cheat: most other aspects of assmbler state still cannot be saved and restored. In general, it would be useful if gas supported some general reflective abilities: i.e., the ability to query the current assembler state (section, subsection, active instruction set, active macro mode, etc.) and/or the ability to wrap or hook existing pseudo-ops. For example, the above problem would almost certainly solvable using assembler macros (albeit painfully) if wrapper macros could be defined for the section manipulation directives (section, .text, .data, .bss, .pushsection, .popsection, .previous). However, supporting some magic macro parameters reflecting the assembler state would be a lot simpler. As an example of the kind of behaviour I think would be useful, the macro argument qualifier could be extended to allow macros to query the assembler state in a backwards-compatible way; something like: .macro fixup base_section:gas_current_section_name, old_altmacro:gas_macro_mode .altmacro LOCAL fixup_location fixup_location: .pushsection \base_section\().fixup .long 100\@b .popsection \old_altmacro .endm Existing assembler code will continue to work just fine with this approach. Note how this also enables a local label to be generated hygenically, by making it possible to save and restore the macro mode. Otherwise, .altmacro (and hence LOCAL) is hard to use safely, since the initial macro mode is unknown and can't be restored. Any thoughts / comments? Cheers. ---Dave

14 years, 7 months

2
3
0 0

[GCC 5.5 - Help on ERROR] Compilation fails with mfpu=neon

by ShankarGanesh Kandasamy

Hi, Following compilation fails with -O3 -mfpu=neon,(but successful on -O2, -mfpu=neon) for Cortex-A5. Could you please help me out to resolve this error ? ubuntu@tegra:~/$ gcc-4.5 -v -c -o utility.o -DLINUX -DUNIX -DHAS_LONGLONG -DLITTLE_ENDIAN_ARCH -DSPEC_CPU2000 -O3 -mcpu=cortex-a5 -marm -mfpu=neon -mfloat-abi=softfp utility.c Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.1/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2) COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'utility.o' '-DLINUX' '-DUNIX' '-DHAS_LONGLONG' '-DLITTLE_ENDIAN_ARCH' '-DSPEC_CPU2000' '-O3' '-mcpu=cortex-a5' '-marm' '-mfpu=neon' '-mfloat-abi=softfp' /usr/lib/gcc/arm-linux-gnueabi/4.5.1/cc1 -quiet -v -DLINUX -DUNIX -DHAS_LONGLONG -DLITTLE_ENDIAN_ARCH -DSPEC_CPU2000 utility.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase utility.c -mcpu=cortex-a5 -marm -mfpu=neon -mfloat-abi=softfp -auxbase-strip utility.o -O3 -version -fstack-protector -o /tmp/ccaZnpsw.s GNU C (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (arm-linux-gnueabi) compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64482 ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabi" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/include" ignoring nonexistent directory "/usr/include/arm-linux-gnueabi" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include-fixed /usr/include End of search list. GNU C (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (arm-linux-gnueabi) compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64482 Compiler executable checksum: 52c4962735600b49ca41dc70631edd04 COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'utility.o' '-DLINUX' '-DUNIX' '-DHAS_LONGLONG' '-DLITTLE_ENDIAN_ARCH' '-DSPEC_CPU2000' '-O3' '-mcpu=cortex-a5' '-marm' '-mfpu=neon' '-mfloat-abi=softfp' as -mcpu=cortex-a5 -mfloat-abi=softfp -mfpu=neon -meabi=5 -o utility.o /tmp/ccaZnpsw.s /tmp/ccaZnpsw.s: Assembler messages: /tmp/ccaZnpsw.s:460: Error: VFP/Neon double precision register expected -- `vmovl.s16 q5,s20' /tmp/ccaZnpsw.s:531: Error: VFP/Neon double precision register expected -- `vmovl.s16 q9,s14' /tmp/ccaZnpsw.s:537: Error: VFP/Neon double precision register expected -- `vmovl.s16 q7,s28' /tmp/ccaZnpsw.s:542: Error: VFP/Neon double precision register expected -- `vmovl.s16 q13,s12' /tmp/ccaZnpsw.s:543: Error: VFP/Neon double precision register expected -- `vmovl.s16 q14,s10' /tmp/ccaZnpsw.s:544: Error: VFP/Neon double precision register expected -- `vmovl.s16 q3,s8' /tmp/ccaZnpsw.s:546: Error: VFP/Neon double precision register expected -- `vmovl.s16 q2,s6' /tmp/ccaZnpsw.s:549: Error: VFP/Neon double precision register expected -- `vmovl.s16 q1,s4' /tmp/ccaZnpsw.s:550: Error: VFP/Neon double precision register expected -- `vmovl.s16 q0,s0' /tmp/ccaZnpsw.s:551: Error: VFP/Neon double precision register expected -- `vmovl.s16 q4,s16' Regards, Shankar -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

14 years, 7 months

1
0
0 0

[ACTIVITY] Jan 24--30

by Chung-Lin Tang

== Last week == * PR47246, VFP index range on Thumb-2. Submitted and committed patch upstream. * Pinged two upstream submissions on gcc-patches, one for PR44557 and the other a patch for LP:689887; still awaiting approval. == This week == * Chinese New Year Holiday, I'll be off until Feb.8th.

14 years, 7 months

1
0
0 0

GCC 4.6 Upgrade Plan

by Andrew Stubbs

Hi All, The GCC 4.6 Upgrade plan can be found here: https://wiki.linaro.org/WorkingGroups/ToolChain/GCCUpgradePlan The plan describes how we should commit "upstream" patches while the FSF trunk is closed, and what we plan to use 4.6 for. Andrew

14 years, 7 months

1
0
0 0

[ACTIVITY] 24th -28th January 2011

by Andrew Stubbs

Created a Google docs spreadsheet to help visualise the benchmark results. The graphs are not very informative yet - too many lines and too much noise. I'm going to have to revisit them. Continued trying to build Android. The toolchains build fine, but Android itself complains about -Werror, and there are a few other real errors too. Considering I was told it built fine with GCC 4.6 and all I needed to do was tweak 4.5 to match, I'm not terribly impressed. I'm sinking too much time into fixing up Android, and I haven't even got to looking at the compiler trouble. Alexander Sack has said he will try to get me to a more appropriate starting place (I think), so I'll see what happens there. Discussed my maddhidi4 patch with Richard E (wearing his GCC ARM maintainer hat). He's not convinced that my change won't make something else produce worse code. I can't prove that it won't either, so I'm going to have to revisit it. Wrote up the GCC 4.6 branch policy and upgrade plan.

14 years, 7 months

1
0
0 0

New phone number for today's call

by Michael Hope

Just a reminder that the dial-in numbers for today's and all future calls has changed. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings for the new list. I'll hang out on IRC just before the meeting to help the lost... -- Michael

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 04

by Peter Maydell

RAG: Red: Amber: Green: qemu-linaro RC0 prerelease uploaded Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-01-11 | 2011-01-11 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | * maintain-beagle-models: + went through diffs between qemu-linaro and qemu-meego to confirm we hadn't dropped any patches by mistake + tested qemu-linaro tree on ubuntu netbook image: boots OK + investigated and fixed qemu bugs caused by new x-loader https://bugs.launchpad.net/qemu-linaro/+bug/704484 and new u-boot: https://bugs.launchpad.net/qemu-linaro/+bug/703094 + made merge requests to meego for a CRIS compile failure and the x-loader bugfix http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/4 http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/5 + Went through the process of doing a qemu-linaro release with a "RC0" prerelease as a pipecleaning exercise and to provide a tarball to slangasek for doing packaging. Download: https://launchpad.net/qemu-linaro/+milestone/2011.02 Release process writeup: https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess * merge-correctness-fixes + the usual upstream mailing list monitoring and code review + tested and sent meego VQ(R)DMULH.s16 fix upstream: http://patchwork.ozlabs.org/patch/80725/ + working on a patch to fix decoding of the preload and hint space 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

14 years, 7 months

1
1
0 0

[ACTIVITY] 2011-01-28

by David Gilbert

SPEC Tried to track down what was going on with lbm; it doesn't seem to be repeatable on canis1; I'd previously seen it fail at O1 and work at O0 and tried to chop down the flags between the two; but after adding all the flags back in on top of -O0 it still worked and then I tried -O1 again and it worked. Going to try on another machine, but it might be uninitialised data somewhere. Panda Our panda arrived; it's now happily nestling near our Beagles and running the 0126 headless snapshot (with 0127 hwpack). It seems fine except for rather slow USB and SD IO. Tip: Panda's do absolutely nothing (no LEDs, no serial console activity) unless you put an SD card in with the firmware on. Libffi Wrote the changes for armhf. Tested on arm, armhf, i386, ppc and s390x - all happy. (Not too unsuspectingly variadic calls just work on everything other than armhf without the api change) Mailed Python CType list asking how much of a pain the API change will be and any hints on what might be affected. Awaiting sign off for submission of code. Optimised library routines Looked at benchmarking 'git'; I'd seen previous discussions where it had been pointed out that it spends a lot of time in library routines; and indeed it does spend useful amounts in memchr, memcpy and friends on a simple git diff v2.6.36 v.2.6.37 > /dev/null of the current kernel tree produces a useful ~25second run. One interesting observation is that the variation in the times reported by 'time' - i.e. user, system and real, the variation in user+system is much less than either user or system individually and is quite stable (within ~0.7% over 10 runs). I've just tried preloading my memchr routine in and it does get a consistent 1-1.2% improvement which does look above the nice. Also asked on libc-help list for suggestions as to other benchmarks people actually trust to reflect useful performance increases in core routines as opposed to totally artificial ones. Dave

14 years, 7 months

1
0
0 0

[ACTIVITY] Jan 24 - Jan 28

by Ulrich Weigand

== GCC == * Determined root cause of #Bug 598462 (corrupted profile info with -O[23] -fprofile-use), identified work-around (using -fprofile-correction), and verified on GCC 4.5 and 4.6 == GDB == * Worked on re-implementation of fix for #615978 (Failure to software single-step into signal handler) 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, 7 months

1
0
0 0

[Activity] Jan 24-28

by Ramana Radhakrishnan

== GCC == * Internal ARM tasks that kept me busy for some time this week. * Reworked the divmodsi4 patch based on comments. Still some test failures that need to be investigated. * Started working on the performance improvement plan for GCC 4.5. * Number of patch reviews upstream. * Looking at A9 memset issue. . * Got an internal bug report about the 4.4 tools from someone using it which had to do with a missing backport. This is now lp:709329. Backported and testing. * Backported a missing upstream patch into GCC 4.5 for bswap patterns. * Wrote up on how to cross-test with qemu and updated that on the Linaro wiki. Comments are welcome. Plans: * Find out the default number of iterations needed for steady state with EEMBC. * Finish testing fix for lp:709329 and get that committed. * Finish off divmodsi4 patch and get it's testing completed and finished. * Submit backport for bswapsi at Os fix (PR44392) for gcc-linaro * Finish the plan for GCC performance improvements based on what we discussed at the sprint. * Away 2-1/2 days next week for an internal engineering conference.

14 years, 7 months

1
0
0 0

[ACTIVITY] Status 2011-01-28

by Richard Sandiford

This week ========= - On other IBM duties until today. Now finished! - Looked at the neon failures that Peter reported. I'm testing patches for the ICE and the "must be a constant" error now. - In the background, I've been trying to pin down the chromium build failure. I can only reproduce it when running under dpkg-buildpackage: if I run the link line manually, it works. This is reminiscent of a problem that Dave saw elsewhere: the linker segfaulted only when run through the normal build system. Next week ========= - Bernd Schmidt has committed our combined patch for #695302. Will backport to our sources. - Submit the neon fixes above. - More on STT_GNU_IFUNC. There are some more tests I want to write. Richard

14 years, 7 months

1
0
0 0

neon intrinsics test cases from ST

by Peter Maydell

Some news from the qemu mailing list that I think might be of interest to gcc folks here: Christophe Lyon from ST has kindly released a large set of test cases of Neon intrinsics: http://gitorious.org/arm-neon-tests/arm-neon-tests (the tests themselves are more aimed at testing qemu, so they just produce output to be compared against a reference generated from running on hardware). However they don't currently compile with gcc (but are ok with armcc). From the README: # The tests currently fail to build with GCC/ARM: # - no support for Neon_Overflow/fpsrc register # - ICE when compiling ref_vldX.c, ref_vldX_lane.c, ref_vstX_lane.c # - fails to compile vst1_lane.c # - missing include files: dspfns.h, armdsp.h Maybe it's worth somebody having a look at this, at least enough to find out whether the ICEs are things we already know about or have perhaps already fixed in linaro gcc? thanks -- PMM

14 years, 7 months

5
4
0 0

[ACTIVITY] January 23-27

by Ira Rosen

Hi, I am working on implementation of interleave_high/low and extract_even/odd for NEON. The pairs of high/low (even/odd) are "magically" united into single vzip (vuzp) instruction in the back end, so there is no need in special support from the tree level. There are still some test failures that I need to solve. Ira

14 years, 7 months

2
2
0 0

Cross testing using qemu.

by Ramana Radhakrishnan

Hi, I've written up a wiki page finally on the cross-testing with qemu here. It's taken me slightly longer than expected as I was playing around with moin-moin syntax. These are based on qemu-0.13.0 which is what I tried when I wrote this up for some testing of a patch that I was playing with. https://wiki.linaro.org/WorkingGroups/ToolChain/CrossTestingQemu Comments are welcome . Ramana

14 years, 7 months

2
2
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * I looked into the perf utility with regard to ARMv7 and raw event support * https://wiki.linaro.org/KenWerner/Sandbox/perf * testsuite fixes for the OpenCL GDB * started to setup the pandaboard (currently the headless snapshot hangs shortly after I got the bash prompt - I'm not sure what's going on here) * On Friday I'll attend a class. Regards Ken

14 years, 7 months

1
0
0 0

[ACTIVITY] January 23-27

by Revital1 Eres

Hello, * Submitted to mainline the patch to model Doloop for ARM (http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) . The ARM back-end part was reviews by Richard Earnshaw. * Looking into EEMBC/DENbench for opportunities applying Modulo-Scheduling. Based on partial profiling information there are SMSed hot loops. My next step is to generate complete profiling information (including gcov info) and execute the benchmarks on ARM machine. Thanks, Revital

14 years, 7 months

1
0
0 0

Re: Neon Support in kernel

by Dave Martin

Hi Vijay, On Sat, Jan 22, 2011 at 9:59 AM, Vijay Kilari <vijay.kilari(a)gmail.com> wrote: > Hello Dave, > > Thanks for this info. > > I have few more queries after looking at the results of memset on A9 & A8. > I agree that externel bus speed matters in comparision across platforms. > > 1) Why memset is performance is good on A8 than A9?. any justification? I've CC'd the linaro-toolchain list who have been working on this topic and may be able to provide you with more information. Cheers ---Dave

14 years, 7 months

3
2
0 0

2011.01 release failure writeup

by Michael Hope

Hi there. I've had a think and done a write-up on the causes behind the 2011.01 release failure and what should be changed. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Incidents/2011.01-X86_64 The changes involve being more explicit in the release process document and changing the continuous build to give earlier warning. Comments are appreciated. -- Michael

14 years, 7 months

1
0
0 0

Testing a GCC patch for ARM

by Revital1 Eres

Hello, I have a patch for ARM that I want to test and I'm not sure what's the procedure of testing in Linaro nor to where it should be committed. (GCC trunk? it's currently under bug fixes mode only). I appreciate help with that. Thanks, Revital

14 years, 7 months

2
3
0 0

Bug fixes for -Os issues in GCC 4.5.x in Linaro?

by Wolfgang Denk

Hello, could you please provide some comments about the state of "-Os" (optimising for size) in the gcc 4.5.x versions of Linaro's tool chain? It appears there are a number of issues with recent versions of GCC that get triggered when optimising for size, for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392 Some other projects like the Linux Foundation driven Poky (resp. Yocto project) capitulated and stopped using -Os, see for example here: http://thread.gmane.org/gmane.linux.embedded.poky/2311/focus=2565 On the other hand, I can see that Linaro even adds improvements for "-Os", see for example here: http://thread.gmane.org/gmane.linux.linaro.toolchain/367 So I wonder what the state of these problems with "-Os" is in the Linaro tool chain? Have these issues been solved, and is "-Os" reliably working with the Linaro tool chain? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de The optimum committee has no members. - Norman Augustine

14 years, 7 months

4
3
0 0

toolchain calls moving to new call number?

by Peter Maydell

I assume we're moving the toolchain calls over to the new confcall numbers -- but just to check, are we doing so for this Wednesday's status call? The calendar entry still has the old numbers... -- PMM

14 years, 7 months

2
1
0 0

[Activity] Jan 10-21 2011

by Ramana Radhakrishnan

==GCC== Progress: * Got invited to the Toolchain WG and was at the sprint in Dallas. * Worked on fixing inconsistencies in the A9 scheduler. Now fixed up upstream and submitted merge request for that. * Introduced to other members of the Toolchain WG and had conversations with everyone about what was going on within the Toolchain WG. * Spent some time trying to set up a Pandaboard that I borrowed (Thanks Wookey) but the Panda didn't work. Turns out both the SD cards were broken and or the versions of the boot loader / firmware were broken. * Worked through the patch list with Andrew trying to understand the patches that exist in the backend for the delta between gcc-linaro and upstream. * Did some patch review upstream to help ease the backlog. * Flushed some patches out from my patch queue upstream. * Fixed the scheduler issue upstream and submitted a merge request for it in linaro gcc-4.5 since it really fixes the A9 scheduler. * Some ARM internal tasks with respect to transition into Linaro. * Worked on the divmodsi4 issue and testing my patch with trunk. Pushed my branch into launchpad if someone wants to see the code. Does the right thing for the case we want but won't help with the SPEC2k case really because that's a case with Os. But a good size improvement anyhow and something that will help with divmod cases with 2 variables rather than where a constant is used. * Set up a natty chroot on one of our ve2 boxes which is now running a bootstrap for all languages we are interested in and collecting test results from trunk upstream. * Worked through the new starter guide and still have an issue with accessing wiki.linaro.org Absences: February 1-3:ARM Internal engineering conference.

14 years, 7 months

1
0
0 0

[ACTIVITY] Jan 17 - Jan 21

by Ulrich Weigand

== GCC == * Analyzed root cause of #685352 (libplymouth2_0.8.2-2ubuntu6 and later give ragged splash and text rendering), opened mainline bugzilla PR rtl-optimization/47299 * Submitted backport merge request for the #685352 fix * Successfully completed profiled-bootstrap run on ARM * Investigated profiled pyhton package build problems == GDB == * Forward-ported GDB patch to support ARM hardware watchpoints * Determined root cause of #615978 (Failure to software single-step into signal handler), started discussion of proposed fix * Miscellaneous Launchpad bug maintenance 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, 7 months

1
0
0 0

[ACTIVITY] 2011-01-21

by David Gilbert

=A9 Qemu= I've spent most of the week looking at QEmu emulation of SMP A9. The model (of a realview-pbx-a9) doesn't have any working block IO; I spent some time looking at trying to get SD working and got part way, but I fell back to using NFS root. It seems to work OK for basic CPU emulation, and SMP 'works' in the sense that the guest sees multiple CPUs; however QEmu is restricted to only using one host CPU core for multiple guest CPUs, so it's of limited help in debugging SMP code. Video doesn't seem to work either. To get to that point it does need a bunch of patches to QEmu, most of which Peter Maydell already knows of; I've put some notes here : https://wiki.linaro.org/Internal/People/DaveGilbert/QEMUA9SMP Note that the realview-pbx doesn't currently have a Linaro hardware pack; I used a kernel from ARMs website and a 2.6.37 I built myself. =SPEC= SPEC ref got quite a far way through on Canis (with half-duplex ether), however 'lbm' failed when running in ref mode (while having worked in test and train) giving a different output; it takes quite a long time to fail. = Perf = I sent an updated version of my patch for perf's thumb annotation upstream. and apparently we have a Panda on the way. Dave

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 03

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | first qemu-linaro release | 2011-01-11 | 2011-01-11 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | * submitted meego patch upstream to print instruction boundaries in TCG op-level debug dumps: http://patchwork.ozlabs.org/patch/79298/ * reviewed a couple of patches by Christophe Lyon from ST which fix some problems with VMULL and friends (together with a qemu-meego patch in the same area) * lots of rebasing work to get a qemu-linaro tree into shape. Mostly putting together my exploded set of ARM patches from the meego tree with a rebased set of omap patches. I have something which I think is about right but I need to test it. * patches submitted to qemu upstream: + add -version option to qemu-user: http://patchwork.ozlabs.org/patch/79635/ + fix writing default vector address in PL190: http://patchwork.ozlabs.org/patch/79712/ + print instruction boundaries in TCG op-level debug dumps: http://patchwork.ozlabs.org/patch/79298/ 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

14 years, 7 months

1
0
0 0

A play with benchmarks

by Michael Hope

I had a few spare cycles this afternoon on my A9 board so I got it to build and run 72 variants of CoreMark with the 2011.01 compiler. The results are here: https://wiki.linaro.org/MichaelHope/Sandbox/CoreMark1 I haven't looked deeply into it and the usual disclaimer about benchmarks applies, but there's some interesting stuff there. The ARM to Thumb-2 drop is more than expected. Tuning for Cortex-A9 generally makes things worse. -- Michael

14 years, 7 months

1
0
0 0

ARMv7-a / Thumb2 etc.

by Ramana Radhakrishnan

Hi, One of the things that came up in yesterday's chat was about ARM vs Thumb2. If some folks are interested in a high level overview that doesn't go into too many details with respect to the ISA that I know a compiler writer will be interested in you could read this presentation unless you've seen it. At the minute the canonical way of figuring out more about Thumb2 is really to read the ARM-ARM. https://wiki.ubuntu.com/Specs/M/ARMGeneralArchitectureOverview?action=Attac… This was a presentation that Dave Rusling gave at the UDS in Belgium last year, it roughly covers the architecture at a high level and talks about Thumb2 vs ARM , why Thumb2 , the evolution of the ARM architecture etc. It's not a lot of detail but quite a high level overview. HTH cheers Ramana

14 years, 7 months

1
0
0 0

[ACTIVITY] January 16-20

by Ira Rosen

Hi, * finished SLP for reduction patch. The loop in DenBench that needs this feature also requires support of load permutation. I am considering to implement that too. I looked for other occasions that need this feature, but only found loops that are not vectorizable. So, I am not sure I'll proceed in this direction. * looked into extract_even/odd and interleave_high/low implementation on ARM as a backup plan for the case we don't have special load/store support on time for the next release. Even though NEON VZIP and VUZP instructions can perform both even and odd (and high and low) computations simultaneously, I don't see how we can express that at the tree level. * looking into ffmpeg * non-Linaro issues Ira

14 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain