linaro-toolchain

linaro-toolchain@lists.linaro.org

5 participants
5577 discussions

by Michael Hope

Hi there. We have a Toolchain WG has a Versatile Express board coming our way. It's a quad-core Cortex-A9 with 1 GB of RAM, so quite decent really. Does anyone have a pressing need for it? If not then I'll take it and make it available over SSH. -- Michael

14 years, 8 months

Toolchain WG - 2010-08-24 meeting minutes

by Michael Hope

Please find the activity reports and minutes for Monday's meeting below. The minutes are also available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-23 Minutes from the Wednesday and Friday standup calls are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-18 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-20 -- Michael Attendees • Name Email IRC Nick Andrew Stubbs andrew.stubbs(a)linaro.org ams Chung-Lin Tang cltang(a)codesourcery.com cltang Matthias Klose doko(a)canonical.com doko Michael Hope michael.hope(a)linaro.org michaelh Peter Maydell peter.maydell(a)linaro.org pm215 Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw Yao Qi yao.qi(a)linaro.org yao Agenda • Open tickets □ 616141 Backport the sync_* primitive fixes □ 590696 fix wrong use of objdump during cross build □ 600277 Backport ARM Cortex A9 scheduling changes □ 605059 Merge 4.4.5 • Upcoming release □ GCC 4.4 □ GCC 4.5 □ GDB □ Strings • 4.6 backport approach • Creating blueprints • Connecting with other groups Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • ACTION: Chung-Lin to move the list of other backports out of the CSL wiki and into Linaro • ACTION: Michael to re-check with TSC that we can assign copyright but keep ability to relicense • ACTION: Yao to continue on GDB for a week then switch to investigation • ACTION: Peter to check into the state and progress of valgrind for the meeting on the 30th. Action Items from Previous Meeting Minutes Tickets: • Went through the open tickets in the agenda • Andrew will backport the SMP changes, including the sync primitives • Andrew will backport the A9 changes □ Most of the changes should come through easily □ There is a write after write hazard □ Currently uses the new cost infrastructure □ Backport the cost infrastructure if it will be used further in the future 4.6 branch: • Andrew suggested starting a 4.6 branch after the start of stage 3 □ Start landing patches early □ When FSF 4.6.0 comes out, we will have a corresponding Linaro 4.6.0 • ACTION: Chung-Lin to move the list of other backports out of the CSL wiki and into Linaro String routines: • Richard asked about the response • Michael had replies from Roland McGrath (http://sourceware.org/ml/ libc-alpha/2010-08/msg00029.html) but not the wider gcc-sc • All other architectures are LGPL and FSF assigned • The current approach is to assign a particular version to glibc • Could cause a small maintenance problem in the future • Richard isn't sure that we can assign copyright of a particular version • ACTION: Michael to re-check with TSC that we can assign copyright but keep ability to relicense 4.6 backports: • Talked about the approach for backporting 4.6 features • Won't backport every single change as then Linaro 4.5 becomes FSF 4.6 • Backport correctness fixes as the problem is found • Backport performance changes as they occur • Discussed how upstream could be tracked □ Notification of any CSL or ARM authered changes will come from them □ All changes are supposed to go through gcc-patches □ Andrew notes that gcc-cvs provides a filtered view of what actually landed □ At least monitor these lists and search for ARM|Thumb|NEON|XSCALE| Cortex|Coretx|VFP|Snapdragon|OMAP Michael noted that IBM are interested in the ARM compiler and plan to get involved soon. Michael has asked again for A9 hardware. No news yet. Future: • Would like to spend some time soon running invetigrations to spit out some blueprints • ACTION: Yao to continue on GDB for a week then switch to investigation • Andrew noted that there is one more person to come from CSL • Will ask that person to do investigation • Richard is keen to see the blueprints to check against what ARM is doing □ Michael asked for information about their planning process so that we can line things up Valgrind: • Peter noted that the valgrind changes have been committed upstream • ACTION: Peter to check into the state and progress of valgrind for the meeting on the 30th. Next meeting is a stand-up meeting on 2010-08-25 on the public code. --- Andrew Stubbs == GCC 4.5 == * Continued pushing 4.5 patches to Linaro. I have now caught up with current development I think. * Lots of discussion on the patch tracker. You'd think it was more important than the compiler .... :( == Upstream == * Did before and after tests of the Coretex-A5 scheduler against upstream HEAD. All seemed well (or at least, no worse) so I've posted the patch upstream. No word back yet .... --- Chung-Lin Tang == Hard-float == * Testing EEMBC softfp vs. hard-float calling convention performance numbers. * The only conclusive result was that OAmark is 2%-3% faster, presumably due to vector graphics-like code in that suite. May look into other code (was suggested Cairo) to see if any gain in changing to hard-float. * Withdraw earlier comment on small improvements on Automark (was not apparent after more experiment runs). * Currently working to produce report files. == Linaro GCC == * Looking at getting into GCC backport work this week. --- Yao Qi == Linaro GDB == * LP:615997 gdb.dwarf2/dw2-ref-missing-frame.exp failure Patch is committed to gdb mainline. * LP:615999 gdb.gdb/selftest.exp failure Patch is committed to gdb mainline. * LP:615995 gdb.base/watch-vfork.exp : Watchpoint triggers after vfork (sw) (timeout) With Pedro's help, got to know the failure of this case on arm and x86 are different. Created a patch as Ulrich suggested, and it works on 2.6.32, while fails in a different way on 2.6.35. Failure is caused by debuggee process is killed by a SIGTRAP. Still no clue why that can happen. == Linaro GCC == * My patch to PR45094 is approved, and checked in to mainline. == This Week == * Fix LP:615995 and other linaro gdb bugs. --- Ulrich Weigand == GCC == * Collected and wrote up suggestions for future GCC work == GDB == * Opened Launchpad bugs for known GDB problems and testsuite failures * Investigated bug #620595 (gdb.threads/threxit-hop-specific.exp failure) * Fixed bug #615998 (gdb.gdb/observer.exp failures) in mainline and 7.2 * Worked on upstream fix for #620595 (gdb.threads/threxit-hop-specific.exp failure) * Analyzed bug #620611 (Unable to backtrace out of vector page 0xffff0000) == Infrastructure == * Continued working with our order&control team to acquire IGEPv2 boards --- Peter Maydell RAG: Red: None Amber: ARM legal OK for qemu contributions still pending Green: we have approval for laptops for linaro secondees Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | 2010-08-27 | | Progress: virtio-system: - got my versatile kernel/qemu running with virtio disk and network versus non-virtio - ran some basic benchmarking (bonnie++ for disk, tbench for net). Disk is faster with virtio, but strangely networking is not! - tried an upstream qemu too -- net virtio still slower - built a realview kernel in preparation for testing Arnd's PCI patches on hardware qemu-focused-kernel: - some research into which ARM dev boards support PCI in hardware, kernel and qemu, to try to find a good choice for basing a qemu-focused kernel on merge-other-branches: - started compiling list of qemu branches for possible consolidation Issues: the intersection of (recent ARM hardware) (PCI support) and (supported in qemu) looks suspiciously like the empty set. Plans: virtio-system: - borrow some versatile or realview hardware and test Arnd Bergmann's PCI patches - make a start on writing up the config/benchmark results qemu-focused-kernel: - flesh out this blueprint valgrind: - try to build an ARM valgrind from upstream's thumb branch Absences: Friday 5 November and 20 other days in this calendar year

14 years, 8 months

Toolchain WG - 2010-08-18 stand up minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-18 I'm going to stop sending out emails about the stand up minutes and include links the weekly minutes instead. Trick of the day: w3m -dump https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-18 | xclip -selection clipboard ...dumps a web page straight into your clipboard for pasting into an email client. -- Michael Attendees • Name Email IRC Nick Andrew Stubbs andrew.stubbs(a)linaro.org ams Yao Qi yao.qi(a)linaro.org yao Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Peter Maydell peter.maydell(a)linaro.org pm215 Julian Brown julian(a)codesourcery.com jbrown Loïc Minier loic.minier(a)linaro.org lool Michael Hope michael.hope(a)linaro.org michaelh Chung-Lin Tang cltang(a)codesourcery.com cltang Agenda • Standup meeting Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting Action Items from Previous Meeting • DONE: Michael to think about synchronising Linaro releases with upstream • DONE: Michael to organise a call with Matthias, Loic to continue the topic • DONE: Michael to write up and email patch tracker mechanics for review • DONE: Ulrich to add his time away to the Linaro calendar • ACTION: Michael and Ulrich to add GDB new features as blueprints to Launchpad • ACTION: Andrew to look into frequent runs of CSL benchmarks • ACTION: Michael to make sure Linaro has a FSF copyright assignment agreement Minutes • Michael □ Continuing on patch tracking □ Continuing investigating string routines □ Julican noted that using NEON adds power usage and adds a context switch cost • Andrew □ Has a few patches left to go □ The ones left are a bit curlier □ Reviewing the upstream state of the current patches □ Will be sending the Cortex-A5 work upstream • Yao □ is continuing with the GDB bug fixes □ Most are caused by the testsuite □ Michael noted that we want to make any work we do available early. If landing on trunk, either backport to 7.2 or note for later pulling into our branch • Ulrich □ Working on bugs such as: ☆ Tracking thumb bit on a long jump ☆ Tracing in the kernel stubs □ Is currently working upstream □ Mentioned the ICACHE flush problem seen on Michael's board ☆ ACTION: Michael will try to upgrade the kernel from Angstrom 2.6.32 to a Linaro kernel • Peter □ Continues on virtio and QEMU □ Network benchmark currently shows virtio performing worse than emulated □ Looking upstream to see if this problem exists □ Still waiting on approval to release work. Richard will take care of next week • Chung-Lin □ Starting on hard vs soft FP performance tests □ Testing on a i.MX51 board □ Michael wants Chung-Lin to finish up on libffi soon • Julian □ Working on a vector conditions patch □ Currently seeing a segfault in compiled applications □ ACTION: Michael will re-try the build failures that Julian saw by the end of this week Next meeting is a stand-up meeting on 2010-08-20 on the public code.

14 years, 8 months

Patch Tracking Use Cases

by Andrew Stubbs

The patch tracking conversation has got a little out-of-hand, and I know I've misunderstood some of the features Michael has been proposing, and I suspect vice versa. So, here's my attempt to compare and contrast the various advantages, disadvantages, and differences of the ideas so far, by means of use cases. Looking at this, I think we can probably come up with a solution that uses the good bits from each (maybe method 1 with the milestone/status policy from method 2, for example). Please read the below, and let me know if I left anything out, or if I misunderstood something. Andrew ==== For the purposes of this document: * Method 0 is my original patch tracker, here: https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.5UpstreamPatches * Method 1 is Michael's proposed patch tracker, here: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%201 and here: http://ex.seabright.co.nz/helpers/patchtrack * Method 2 is my proposed system, here: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%202 --------------------------------------------------------- 1. What does a user have to do to get a patch tracked? Method 0: Nothing. New rows are added to the wiki page regularly by a script and cron-job. Method 1: Nothing. The tracking report is updated regularly. Method 2: Nothing. New tickets are created automatically, regularly. ------------------------------------------------------------ 2. How to find tracking information for a revision? Method 0: Search the wiki page for the revision number. Method 1: Goto the report page, click through to all the various associated tickets, if any. Method 2: Go to launchpad, and search for "r123456", or select it from the list in the relevant gcc-linaro-tracking milestone. ------------------------------------------------------------ 3. How to find tracking information for a bug fix? Method 0: Search the wiki page for the bug number - hopefully somebody has posted a link. Alternatively, the first line of the commit message will be present. If that doesn't work, then find the revision number by other means (bzr). Method 1: Go to the bug ticket - it should be there, or a link to another bug that has it. Alternatively, go to the tracker report page, and search for the commit message. If that fails try to identify the revision number by other means (bzr) Method 2: Go to the bug ticket - if the bug was committed with --fixes, there will be a link to the tracking ticket. Alternatively, search gcc-linaro-tracking to find the commit message. If that fails try to identify the revision number by other means (bzr) ---------------------------------------------------------- 4. How to add new tracking information? Method 0: Edit the wiki page. Method 1: Add the new information to one or all of the associated bugs, if any. If there are no existing tickets, create a new ticket (using the link on the tracker report) and put the information there. Method 2: Add the information to the ticket. ----------------------------------------------------------- 5. How to indicate that the bug is upstream? Method 0: Edit the wiki page, set the bgcolor to green. Method 1: Assign all the bug tickets to a gcc-linaro-tracking milestone. Method 2: Mark the bug "Fix committed". Ensure that the ticket has the correct milestone. ------------------------------------------------------------ 6. How to list all patches that need to go upstream? Method 0: View the wiki page - the patches are highlighted in red and yellow. Method 1: View the tracker report - the patches are highlighted in red, yellow, and orange. (Note that launchpad will only list the patches that already had a ticket attached, or else somebody has create one. This will usually only include patches where somebody had something to say about it.) Method 2: All open bugs in gcc-linaro-tracking. ------------------------------------------------------------- 7. How to list all patches that need forwarding on rebase from 4.5 to 4.6? Method 0: Any patches marked in red or yellow on the wiki page need forwarding. Any patches marked in green with an upstream landing number of 4.7 or higher also need forwarding. (This information is not yet encoded in the page, but it's a wiki, so flexibility is not a problem.) Any patches in grey also need considering. Some are uninteresting version bumps and such. Some are patches we plan to carry forever. Probably a new colour could be used to make this clearer - it's a wiki. Method 1: Any patches in the report not yet upstream need forwarding. Any patches in launchpad against the 4.7 milestone (or higher) also need forwarding. Any patches in the "never" milestone also need considering. Some might be ancient patches we used to carry in 4.4, but have since been dropped. Some will be patches we intend to carry. Method 2: All patches against the 4.7 milestone, both open and closed (modify the launchpad search criteria) need forwarding. All patches in the "series:never,milestone:4.5" milestone in the "won't fix" state need forwarding. (Patches we don't intend to carry forward will be "closed", and patches from 4.4 won't be in "series:never,milestone:4.5", so we never have to worry about those.) ------------------------------------------------------------------ 8. How to we track what patches have been forwarded on rebase already? Method 0: It's a wiki, add a column. Method 1: Committing the patch on a new branch will (with --fixes) will cause launchpad to list the commit on the bug page. There's no way to query this though. Method 2: Committing the patch on a new branch will give a "new" patch to track. The trackerbot will create a new ticket for this revision. The old ticket will be marked as a "duplicate" of the new one (manually, or automatically). The new bugs will have "4.6/r123456" in the subject line, so can be easily be differentiated. ----------------------------------------------------------------- 9. What else needs doing on a rebase? Method 0: Create a new page with a new table. Forward the information from the old table manually, by editing the wiki. Method 1: Create a new tracker report. Method 2: Set up the trackerbot on the new branch. ------------------------------------------------------------------ 10. What prompts users to use the system? Method 0: Nothing. (Management nagging.) Method 1: Nothing mentioned so far. Method 2: The bug is always assigned to somebody. They'll be notified by email, and it will show up on their launchpad pages. ------------------------------------------------------------------ 11. What happens when a bug produces multiple patches? Method 0: Multiple lines in the table, initially. But, it's a wiki, so they can be edited, moved around, and coalesced as required. Method 1: The same bug has to track multiple patches. ????? How does that work with the 'affects gcc-linaro-tracking' lines? Method 2: One ticket per commit. Each is tracked separately, but the user is free to mark each ticket as a duplicate of the other, and/or move the data from one ticket to another. ------------------------------------------------------------------ 12. What happens when one commit fixes multiple bugs? Method 0: Nothing special. Method 1: Multiple bugs will track the same submission process. Either the user must post all the data to all the bugs, or one bug must get (manually) appointed the master bug, and the others have links posted. Method 2: One ticket will be created to track the patch. The ticket will contain links to all the bugs, and each bug will contain a back-link. This is very little different to the normal case.

14 years, 8 months

Patch tracking method

by Michael Hope

I've fleshed out a potential way of tracking patches at: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%201 It's not too bad if you're a developer. The extra steps are: * Create a ticket * Mark that ticket as affecting upstream * Change the status as the patch evolves * Mark where the patch lands when finished This is all done through Launchpad's existing interface. Thoughts? -- Michael

14 years, 8 months

Re: [Bug 620229] [NEW] [4.5:r99360] Code hoisting improvements

by Michael Hope

Sorry about these. Hopefully I'm done. On Thu, Aug 19, 2010 at 2:28 PM, Michael Hope <620229(a)bugs.launchpad.net> wrote: > Public bug reported: > > Related: lp:gcc-linaro/4.5,revno=99360 > > Code hoisting improvements > > Merged from SourceryG++ > > (Backport from FSF) > > ** Affects: gcc-linaro > Importance: Undecided > Status: New > > ** Affects: gcc-linaro/4.5 > Importance: Undecided > Status: New > > > ** Tags: revision > > -- > [4.5:r99360] Code hoisting improvements > https://bugs.launchpad.net/bugs/620229 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in Linaro GCC: New > Status in Linaro GCC 4.5 series: New > > Bug description: > Related: lp:gcc-linaro/4.5,revno=99360 > > Code hoisting improvements > > Merged from SourceryG++ > > (Backport from FSF) > > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/gcc-linaro/+bug/620229/+subscribe >

14 years, 8 months

Dhrystone

by Michael Hope

I know that Dhrystone isn't a very good benchmark, but it's still interesting: https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/Dhrystone If we can get twice the performance out of strcpy() and memcpy() then the Dhrystone result should go up by almost 30 %. It would make a nice headline at least :) -- Michael

14 years, 8 months

Toolchain WG - 2010-08-17 meeting minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-16 Activity reports are included below. -- Michael Attendees Name Email IRC Nick Andrew Stubbs andrew.stubbs(a)linaro.org ams Julian Brown julian(a)codesourcery.com jbrown Loïc Minier loic.minier(a)linaro.org lool Matt Gretton-Dann ARM Matthias Klose doko(a)canonical.com doko Michael Hope michael.hope(a)linaro.org michaelh Peter Maydell peter.maydell(a)linaro.org pm215 Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Yao Qi yao.qi(a)linaro.org yao Agenda • Benchmarks □ ffmpeg (h.264), libmad (mp3), LAPACK, CoreMark, Dhrystone, and memcpy() □ EEMBC □ Methods of benchmarking • Patch tracking □ Minimum features □ Discovering upstream patches to backport □ Example version at http://ex.seabright.co.nz/helpers/patchtrack □ Ticket view at http://ex.seabright.co.nz/helpers/tickets • Upstream tracking □ Ubuntu tracks release+SVN. What should we do? • memcpy() and friends □ https://wiki.linaro.org/WorkingGroups/ToolChain/StringRoutines □ Copyright issues with EGLIBC • Hardware status • Creating blueprints • Connecting with other groups • Open tickets □ 616141 Backport the sync_* primitive fixes □ 590696 fix wrong use of objdump during cross build □ 600277 Backport ARM Cortex A9 scheduling changes □ 605059 Merge 4.4.5 Action Items from this Meeting • ACTION: Michael to think about synchronising Linaro releases with upstream • ACTION: Michael to organise a call with Matthias, Loic to continue the topic • ACTION: Michael to write up and email patch tracker mechanics for review • ACTION: Ulrich to add his time away to the Linaro calendar • ACTION: Michael and Ulrich to add GDB new features as blueprints to Launchpad • ACTION: Andrew to look into frequent runs of CSL benchmarks • ACTION: Michael to make sure Linaro has a FSF copyright assignment agreement Action Items from Previous Meeting • DONE: Richard to ask the GCC developers on IRC what the status of 4.4.5 is □ Matthias talked with Jacob and they expect a release at the end of August • DONE: Andrew to merge 4.5.1 and the Firefox fix by 2010-08-17 • DONE: Ulrich to ticket GDB items • DONE: Michael to understand whiteboards as a way of organising features Minutes Upstream patches: • Loic, Matthias, and Michael discussed tracking the upstream release branch • Upstream has a roughly three week cycle on patch releases • Matthias tracks this release branch and pulls in SVN as a patch into Ubuntu • Michael is concerned about the extra work, pulling a partial □ feature, catching a regression, fallout due to releasing something that upstream hasn't released, • Release branches are very stable. Chance of a regression is low • Better chance of getting a problem fixed upstream if caught early before the release • Loic: harder to track upstream • Loic: also harder to identify a Linaro release - FSF-4.4.4+svr12345+bzr6789... • Matthias spoke with Jacob in GCC. They expect a release at the end of □ August • Michael prefers basing on released versions only • Michael also wants to be able to reproduce any issues found in Ubuntu. Hard at the □ moment as Ubuntu runs Linaro plus a reasonably large set of patches ts to be able • One approach: merge the day after the Linaro release. Gives the maximum time for □ testing. Still a month behind, still have Ubuntu GCC != Linaro GCC • Matthias □ Would continue to keep diff between Linaro and upstream □ Is doing changes upstream □ Would have to maintain those separately □ If there are release critical changes, would have to do them himself • Discussed different phase of Linaro GCC vs Ubuntu - the releases won't be in sync so there will always be a need for release critical fixes in Ubuntu • ACTION: Michael to think about synchronising Linaro releases with upstream □ Drift the Linaro release to be a week later than the upstream release • Andrew wasn't concerned. Noted that the release branches are really good • ACTION: Michael to organise a call with Matthias, Loic to continue the topic Patch tracking: • Cortex-A5 changes are coming into Linaro • Michael did a quick show and tell on the patch tracker hack • ACTION: Michael to write up and email patch tracker mechanics for review Other topics: • Ulrich is out on vacation next week • ACTION: Ulrich to add his time away to the Linaro calendar • ACTION: Michael and Ulrich to add GDB new features as blueprints to Launchpad • Michael noted that we use bzr for version control wherever possible, including for QEMU • Michael asked Andrew if we could start regular runs of the commonly used benchmark • ACTION: Andrew to look into frequent runs of CSL benchmarks • String routines □ Michael talked with upstream and they greatly prefer FSF+LGPL □ ACTION: Michael to make sure Linaro has a FSF copyright assignment agreement • Loic mentioned Valgrind patches □ Peter is interested in helping Next meeting is a stand-up meeting on 2010-18-11 on the public code. -- Julian Brown == GCC 4.5 bugs in Launchpad == * Attempted to reproduce bugs against Linaro GCC 4.5 in Launchpad: issues #614184, #614185 and #614186. The last of these has been closed as invalid by the submitter already, and the first two don't seem to reproduce using a cross-compiler (i.e. using CS's build machinery), nor with a natively-bootstrapped bzr head build (as of some day last week). So, no real progress there. == GCC 4.5 vectorization improvements == * Started tracking down the causes of some failures in vect.exp: pr43430-1.c failed because of missing vector comparison support. This seemed relatively straightforward to implement using NEON instructions, so I had a go at doing that. Similarly another test fails (vect-35.c) because of missing support for widening/narrowing patterns, though I'm still investigating a fix for that. -- Andrew Stubbs == Linaro GCC releases == * Merged GCC 4.5.1 into the Linaro sources. * Respun the 4.5-2010.08 release. == Linaro GCC 4.5 == * Continued pushing SG++ patches into Linaro. I'm now most of the way through these, but I had hoped to have had it done by now. == Other == * Lost a few hours to internet outages. An engineer came out and changed all the connections, so hopefully that's solved the problem. It seems the recent bad weather had got into the underground cables between here and the street cabinet. It's fibre from there, so in theory it must be local. * Took Wednesday as vacation. -- Peter Maydell Subject: [weekly][linaro] report week 32 RAG: Red: None Amber: ARM legal OK for qemu contributions Green: booted versatile+virtio kernel on qemu Milestones: none as yet Progress: virtio-system: - identified which qemu patches give a qemu which can boot linaro alpha-3 on beagle emulation - built a kernel for 'versatile' flavour with virtio support - found some patches from qemu upstream which are needed for newer versatile kernels to boot - got my versatile kernel running on qemu with the linaro rootfs mounted via virtio - put various qemu changes/patches into a git tree, so (a) I know what I changed and (b) as an exercise in learning git Issues: none Plans: virtio-system: - get versatile to boot *without* virtio for comparison - find an io benchmark and do some benchmarking qemu-focused-kernel: - flesh out this blueprint Absences: None planned. -- Chung-Lin Tang == libffi VFP hard-float support == Testsuite fixes and final tuning before submitting. Had to port some stuff from the GCC testsuite to let libffi's testsuite support a dg-skip-if option, to skip some variadic function tests based on compiler options (skip when -mfloat-abi=hard), and I am not a DejaGNU/expect/Tcl expert...:P Whole patch was submitted to main libffi mailing list on Sunday, waiting for feedback. (see http://sourceware.org/ml/libffi-discuss/2010/msg00153.html) == This week == * See if any feedback on libffi patch. * Start Linaro 4.5 EEMBC comparisons. * Catch up on GCC work. -- Yao Qi == Linaro GCC == * Pinged ARM backend maintainer for my patch to GCC PR45094. Still no response. * Submit my patch on ARM target triplet in gcc-patches. With Dan's help, got GCC write access. Checked in my patch. * Update status of LP bugs. Mark them as Fix Released since failures go away in gcc-linaro-4.4-2010.08-0. == Linaro GDB == * Search something about GDB from my brain, like gdb test, tcl/expect, ptrace/breakpointetc. Fortunately, most of them are still there. :) * LP:615997 gdb.dwarf2/dw2-ref-missing-frame.exp failure Failure is caused by alignment of test case. Sent a patch to gdb-patches, and revise it with Dan's help. * LP:615989 gdb.base/pending.exp Failure is caused by wrong code in .debug_line. Failure goes away when it is compiled by gcc-linaro-4.5-2010.08-1. Open a gcc bug LP:617384. * LP:615995 gdb.base/watch-vfork.exp : Watchpoint triggers after vfork (sw) (timeout) Reproduce it on x86. GDB is waiting endlessly between TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORK_DONE. Looks like child of debuggee hangs on 'signal'. == This Week == * Look into LP:615995 deeply, and other linaro gdb bugs.

14 years, 8 months

apr/eglibc issue with shared mutexes

by Loïc Minier

Hi I'm concerned that the workaround for apr was just uploaded in the form of disabling process shared mutexes (see LP #599874), but we didn't address or investigate the root cause in eglibc. Would someone be able to look at LP #604753 where the issue is tracked? Thanks! -- Loïc Minier

14 years, 8 months

2010-08-16 Agenda

by Michael Hope

...is available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-16 -- Michael Agenda • Benchmarks □ ffmpeg (h.264), libmad (mp3), LAPACK, CoreMark, Dhrystone, and memcpy() □ EEMBC □ Methods of benchmarking • Patch tracking □ Minimum features □ Discovering upstream patches to backport □ Example version at http://ex.seabright.co.nz/helpers/patchtrack □ Ticket view at http://ex.seabright.co.nz/helpers/tickets • Upstream tracking □ Ubuntu tracks release+SVN. What should we do? • memcpy() and friends □ https://wiki.linaro.org/WorkingGroups/ToolChain/StringRoutines □ Copyright issues with EGLIBC • Hardware status • Creating blueprints • Connecting with other groups • Open tickets □ 616141 Backport the sync_* primitive fixes □ 590696 fix wrong use of objdump during cross build □ 600277 Backport ARM Cortex A9 scheduling changes □ 605059 Merge 4.4.5 Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • TBD Action Items from Previous Meeting • ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5 is • ACTION: Andrew to merge 4.5.1 and the Firefox fix by 2010-08-17 • ACTION: Ulrich to ticket GDB items • ACTION: Michael to understand whiteboards as a way of organising features

14 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain