- linaro-toolchain - lists.linaro.org

by Zach Welch

Hi all, I was recently hired by CodeSourcery and have been assigned to Linaro for the purpose of improving OpenOCD. Specifically, I will be adding new support for Cortex-A9 SMP, though I may also make a few improvements to its handling of Cortex-A8 in the process. If you have experience using OpenOCD in these contexts, let me know if you have any specific requests for features or fixes, and I will try to fold them into my plans. After this cross-posted introduction, I believe that most of my correspondence will appear on the Toolchain mailing list, but I wanted to make sure that everyone knows that they can find me there. Cheers, -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

15 years, 3 months

5
5
0 0

Linaro GCC 4.4 and 4.5 2010.09 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.4 is the third release in the 4.4 series. Based off the latest GCC 4.4.4, it pulls in the pre-4.4.5 changes made by the FSF over the last six months. Linaro GCC 4.5 is the second release in the 4.5 series. Based off the latest GCC 4.5.1, it finishes the merge of many ARM-focused performance improvements and bug fixes. Interesting changes include: * Improved performance on the Cortex-A9 * Backports of a range of performance improvements from mainline * New inline versions of the GCC builtin sync primitives Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro Also available is an early release of optimised string routines for the Cortex-A series, including a mix of NEON and Thumb-2 versions of memcpy(), memset(), strcpy(), strcmp(), and strlen(). For more information see: https://launchpad.net/cortex-strings Pre-build packages are available in the Linaro Toolchain PPA at: https://launchpad.net/~linaro-toolchain-dev/+archive/ppa -- Michael

15 years, 4 months

5
11
0 0

Thumb2 code size improvements

by Yao Qi

Hi, We are looking for some possible improvements and optimizations on thumb2 code size. Currently, I am running some benchmarks with compilation flag "-Os -march=armv7-a -mthumb", and hope to find some thing interesting that we can improve. Beside that, do you have some ideas on this topic? or do you have some observations on thumb2 code that we may probably improve the size? Any thoughts on this are appreciated. Yao

15 years, 4 months

11
30
0 0

State of cross compiler packages

by Marcin Juszkiewicz

I think that it is easier to describe situation in email then on irc. Currently there are 4 packages related to cross compilation support: - armel-cross-toolchain-base (a-c-t-base in short) - gcc-4.4-armel-cross - gcc-4.5-armel-cross - gcc-defaults-armel-cross Each of them got into archive but they need to be updated to get installable packages. Status of each package: 1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source 4.5.1-6ubuntu1 version. This package is used to bootstrap armel cross toolchain and generates: - binutils-arm-linux-gnueabi (from binutils-source) - libc6(-dev,-dbg)-armel-cross (from eglibc-source) - linux-libc-dev-armel-cross (from linux-source-2.6.35) - gcc-4.5-arm-linux-gnueabi-base, libgcc1(-dbg)-armel-cross (from gcc-4.5-source) libgcc1* packages have /usr/share/doc/ directories as symlinks to /usr/share/doc/gcc-4.5-arm-linux-gnueabi-base/ I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have /usr/share/doc/ directories pointing into gcc-4.5-base one. Need to fix this symlink by providing those files in libgcc1 package instead. 2. gcc-4.4-armel-cross is at 1.36 in archive and was built with gcc-4.4-source 4.4.4-14ubuntu4 version. This package provides compilers, libstc++6-4.4-(dev,dbg,pic)-armel-cross, libmudflap0-4.4-dev-armel-cross and gcc-4.4-arm-linux-gnueabi-base packages. I have 1.38 version ready to upload which fixes #637454 #640298 bugs. 3. gcc-4.5-armel-cross is at 1.35 in archive and was built with gcc-4.5-source 4.5.1-7ubuntu1 version. This package provides compilers and runtime libraries. But it does not provide libgcc1(-dbg)-armel-cross and gcc-4.5-arm-linux-gnueabi-base because they are in a-c-t-base source package. All resulting packages have /usr/share/doc/ directories pointing into gcc-4.5-arm-linux-gnueabi-base one which is policy violation. I have 1.37 version ready to upload which fixes #637454 #640298 bugs and provides gcc-4.5-arm-linux-gnueabi-base package so policy violation is removed. 4. gcc-defaults-armel-cross is at 1.3 in archive and does not require any changes. Main problem is that packages generated from gcc-4.5-source are split into two packages: armel-cross-toolchain-base (libgcc1(-dbg)-armel-cross) and gcc-4.5-armel-cross (all the rest). This was required to allow to bootstrap cross compiler but gives problems when one is built with other version of gcc-4.5-source then other - resulting packages are not installable (we have it now in archive). It is also a thing which Matthias does not like and I understand it. For now my only solution is to build both with one version of gcc-4.5-source. What are your opinions? http://marcin.juszkiewicz.com.pl/download/ubuntu/ is download link for mentioned versions. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 4 months

2
2
0 0

Re: GCC PRE patch; apply or not?

by Steven Bosscher

xf. http://lists.linaro.org/pipermail/linaro-toolchain/2010-August/000069.html > It is not upstreamable due to copyright issues, but we have a policy > that we can keep such patches, if we wish. I wrote this patch. If I am the copyright issue, then there is no issue. I have a copyright assignment for all my GCC work to the FSF. That assignment also covers the patch in the e-mail stored at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html. I consider copyright to all my patches assigned to the FSF if I have submitted the patches to gcc-patches(a)gcc.gnu.org, or attached them to a Problem Report in GCC bugzilla, or both. The only reason why this patch for GIMPLE PRE is not in the FSF GCC already, is that I just never cared enough to pursue it. GCC is just a hobby for me, and experimenting with ideas is fun. Doing all the required testing for inclusion in the FSF GCC is not fun and it costs time that I usually can't find. I am just too busy with other things to clear off this and other pending patches/ideas from my TODO list :-) If you wish to submit this patch for the FSF GCC, please feel free to do so. In fact, I'd encourage you to do so. Likewise for my patch for e.g. http://gcc.gnu.org/PR20070, and for the GIMPLE hoisting pass. Ciao! Steven

15 years, 4 months

1
0
0 0

binutils testsuite Thumb-2 coverage

by Chung-Lin Tang

Hi, about the status of binutils testsuite Thumb coverage (CS204 in the workplan), I have filed two Launchpad bugs: #640263: Testsuite coverage: Thumb-2 VFP/NEON encodings https://bugs.launchpad.net/binutils-linaro/+bug/640263 #640272: Testsuite coverage: Thumb relocations https://bugs.launchpad.net/binutils-linaro/+bug/640272 To summarize: I currently do not see any testing of Thumb-2 VFP/NEON encodings; Thumb mode relocations are also only barely tested in the ld testsuite. Also, please inform if there are any other areas of binutils Thumb testing that may be of concern to Linaro. Thanks, Chung-Lin

15 years, 4 months

2
1
0 0

Thumb2 size optimization report

by Yao Qi

* Goal Goal of this work is to look for thumb2 code size improvements on FSF GCC trunk. * Methodology ** Build FSF GCC trunk w/ and wo/ hardfp, run benchmarks including eembc, spec2000, and dhrystone, and check asm code to see if there is any possible improvements on size. ** Get input and suggestion from ARM experts. ** Search open PRs in GCC bugzilla. * Results Each item has been tracked on launchpad, and is listed with some elements, ** Cause: cause of this problem is known or unknown ** Difficulty: estimation of implementation difficulty ** Recommendation: Yao's recommendation on that bug for next step 1. LP:633233 Push/pop low register rather than high register when keeping stack alignment As Richard E. pointed out, it was implemented in gcc-4.5 on 2009, but Yao still can see the usage of r8 on FSF GCC trunk. Cause: Might be a regression if problem disappears on gcc-4.5. Difficulty: Easy. might not hard to fix a regression. Recommendations: Fix this regression if it is. 2. LP:633243 Improve regrename to make use of low registers. Get input from Bernd S. and Julian B. Initial implementation has been suggested by Bernd S. Cause: current regrename in gcc treats high and low registers equally. Difficulty: Medium. Recommendation: Implement it as Bernd suggested, and do benchmarking to see how much size is improved. 3. LP:634682 Redundant uxth/sxth insn are generated Cause: Unknown Difficulty: Unknown Recommendation: No recommendation so far. 4. LP:634696 Function is not inlined properly with -Os In consumer/cjpeg/jmemmgr.c, GCC inlined out_of_memory() with -Os, so increase code size. Cause: Unknown. Difficulty: Unknown Recommendation: Educate GCC to inline carefully when -Os is turned on. 5. GCC PR40730 LP:634731 Redundant memory load 6. LP:634738 inefficient code to extract least bits from an integer value GCC PR40697 is for thumb-1. The same problem is in thumb-2. Cause: Unknown. Difficulty: Medium. Recommendation: Fix it the similar way as fixing GCC PR40697. 7. LP:634891 Replace load/store by memcpy more aggressively Difficulty: Should be easy. Recommendation: Fix to this problem might be "reduce threshold value once -Os is turned on". 8. LP:637220 allocate local variables with fewer instructions GCC PR40657 is about this kind of problem, and was fixed. The similar prolbme exits on gcc with hardfp. Cause: Unknown. Difficulty: Unknown. Recommendation: No recommendation so far. 9. GCC PR 43721 Failure to optimize (a/b) and (a%b) into single __aeabi_idivmod call Difficulty: Medium or easy. Recommendation: No. 10. LP:637814 Combine add/move to add LP:637882 Combine ldr/mov to ldr Possible improvements have been found. No idea how to fix it yet. Cause: Unknown. Difficulty: Unknown. Recommendation: No. 11. LP:638014 Replace memset by memclr when 2nd parameter is zero Difficulty: Easy. Recommendation: No recommendation so far. 12. LP:625233 Merge constant pools for small functions Cause: Unknown. Difficulty: Medium. Recommendation: No. 13. LP:638935 Replace multiple vldr by vldm Some vldr insns accessing consecutive address can be replaced by single vldm. It is not about thumb2, but related to code size optimization. Cause: Unknown. Difficulty: Medium. Recommendation: No. -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

15 years, 4 months

2
2
0 0

Cross compiling for embedded targets

by Michael Hope

Hi there. I've always wanted to mix this: http://www.futurlec.com/ET-STM32_Stamp.shtml with some of this: http://bit.ly/cD0JPS to control my one of these: http://www.traxxas.com/products/electric/rustler2006/gallery/3705-3qrtr-Bla… and it sounds like a good opportunity to dogfood the Linaro toolchain at the same time. What's the best way to set up a Cortex-M3 toolchain with an appropriate newlib and libgcc? A wrapper script works fine but I need a way of recompiling libgcc for the Cortex-M series. I'd love to get a arm-none-eabi toolchain package out of this that others could use. Could I re-work the cross packaging to use newlib and change the configure flags instead? Are there existing Debianised cross packages that I could reuse? Ta, -- Michael

15 years, 4 months

5
5
0 0

2010.09 build results

by Michael Hope

Hi Andrew. Well, the builds are done and they're OK. I've added the ability to compare against an explicit release to make checking regressions easier. 4.4 results are here: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs… i686 and x86_64 have not regressed since 2010.08. On arm, and ignoring the limits test, 2010.09 adds a failure on gcc.c-torture/compile/991026-2.c. According to the log the run timed out but I can't reproduce it. 4.5 results are here: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs… i686 has not regressed since 2010.08. x86_64 fails on gcc.target/i386/wmul-1.c, but this is a new tests for new features and are not a regression against 4.5.1. arm is messier. The following new failures exist: Vectoriser related: * g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorized 1 loops" 1 * g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorizing stmts using SLP" 1 * gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1 loops" 1 * gcc.dg/vect/vect-multitypes-12.c scan-tree-dump-times vect "vectorized 1 loops" 1 * gcc.dg/vect/vect-reduc-dot-s16b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1a.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1c.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-2b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/wrapv-vect-reduc-pattern-2c.c scan-tree-dump-times vect "vectorized 1 loops" 0 Others: * gcc.target/arm/neon-load-df0.c scan-assembler vmov.i32[ \t]+[dD][0-9]+, #0\n * gcc.target/arm/synchronize.c scan-assembler __sync_synchronize neon-load-df0 is a new test. synchronize.c is an incorrect test as the compiler now correctly uses the dmb instruction. Your thoughts? -- Michael

15 years, 4 months

2
1
0 0

gdb-linaro bzr tree

by Yao Qi

Hi, I tried linaro gdb branch just now, $ bzr branch lp:gdb-linaro parent branch is bzr+ssh://bazaar.launchpad.net/%2Bbranch/gdb-linaro/, which looks strange. In gcc-linaro, parent branch is bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5/ I thought parent branch of linaro gdb tree should be like bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gdb-linaro/7.2/ Is there something wrong in this branch?

15 years, 4 months

1
0
0 0

armel cross toolchain packages available in PPA

by Marcin Juszkiewicz

I would like to announce that my work on armel cross toolchain got to the very nice point - all packages are available from PPA. What does it mean to you? 1. no "are you sure to install those unverified packages" messages from APT 2. ability to easily rebuild toolchain on own machines So if you used my repository from people.canonical.com then please switch to PPA one: add-apt-repository ppa:hrw/armel-cross-compilers Old repository will be available for some time but will not get any updates. Next step: merging those packages into Maverick release. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 4 months

2
1
0 0

Basic benchmarks

by Michael Hope

I've been checking over the benchmarks as a lead up to the 2010.09 release. We're in a good way compared to both 4.4.4 and 4.5.1 for most non-trivial tests. * pybench is 10.9 % faster than 4.4.4 and 7.7 % faster than 4.5.1. * linpack is 46.4 % faster than 4.4.4 and the same as 4.5.1. * ffmpeg h.264 video decode (with hand written assembler versions turned off) is 15.4 % faster than 4.4.4 and 1.2 % faster than 4.5.1. All results are statistically invalid and against poor workloads, but I'll work on that. See http://ex.seabright.co.nz/helpers/benchcompare for more. -- Michael

15 years, 4 months

3
4
0 0

Re: Thumb2 code size improvements

by Yao Qi

Loïc Minier wrote: > I see you moved the wiki page to the public space, thanks > > Couple of notes: > * make sure you use the rename action on the page, I think this will > preserver history (I didn't check whether you did or not, but I think > not) No, I didn't. I use copy and paste. I'll use rename action. > * add a page at the old location with "#redirect NewPage" or > "#refresh 0 http://newurl/" OK, got it. Thanks for your help on wiki.

15 years, 4 months

1
0
0 0

2010-09-06 Toolchain WG Meeting Minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-09-06 A copy and activity reports are included below. -- Michael Attendees • Name Email IRC Nick Andrew Stubbs ams(a)codesourcery.com ams_cs Chung-Lin Tang cltang(a)codesourcery.com cltang Julian Brown julian(a)codesourcery.com jbrown Loïc Minier lool(a)linaro.org lool Marcin Juszkiewicz marcin.juszkiewicz(a)linaro.org hrw 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 Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Yao Qi yao(a)codesourcery.com yao Agenda • Licensing of string routines • State of valgrind • State of GDB • Open tickets □ 600298, 616141, 604753: SMP/sync related □ 605059 4.4.5 □ 629671 ICE in reload_cse_simplify_operands in thumb-1 mode □ 590696 Wrong use of objdump during cross build • Upcoming release • Creating blueprints Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • ACTION: Richard to check with the legal department on string licensing issues • ACTION: Peter to talk with valgrind upstream re: Linaro releasing a ARM-focused version • ACTION: Michael to organise an 'experimental' PPA that toolchain output can go into • ACTION: Michael to talk with Cody Somerville re: building on ARM • ACTION: Michael to set up a GDB 7.2 based off the release tarball • ACTION: Andrew to pull sync changes back into 4.4 for this release • ACTION: Michael to assign appropriate sync ticket to Andrew to track the backport • ACTION: Andrew to merge the current post 4.4.4 release branch into our 4.4 for this release • ACTION: Julian to do a basic investigation into 629671 • ACTION: Andrew to merge the cross-compile objdump ticket into this release and re-kick upstream process Action Items from Previous Meeting • ACTION: Michael to re-check with TSC that we can assign copyright but keep ability to relicense • DONE: 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: Chung-Lin to shift the CSL backport list out onto the Linaro wiki • ACTION: Michael to see about doing an archive rebuild with 4.5 • DONE: Michael to send IBM's list to Yao Minutes String routines: • Michael asked Richard about getting the current str* routines by ARM transferred to Linaro • Linaro will then get these into other C libraries • FSF prefers LGPL and copyright for glibc • Linaro prefers MIT/X11 everywhere so that fixes and improvements can be shared • Richard is concerned about the copyright assignment and any patent grant • ACTION: Richard to check with the legal department on string licensing issues • Extreme fallback is to re-write the routines to all be under Linaro copyright. memcpy() and similar may need this Valgrind: • Peter has been looking at how it works on the ARM platform • Upstream is very responsive to issues • Now works on Firefox and OO.org • Upstrem doesn't have any particular release cycle • ARM changes are pretty extensive and can't be extracted • Peter suggested making valgrind available in a PPA to start with • NEON detection at startup is remaining issue • What next? □ Packaging is straight forward □ Don't want to steal upstream's thunder or release something inappropriate □ ACTION: Peter to talk with valgrind upstream re: Linaro releasing a ARM-focused version • Could bring into the Linaro overlay PPA • ACTION: Michael to organise an 'experimental' PPA that toolchain output can go into • ACTION: Michael to talk with Cody Somerville re: building on ARM GDB: • 7.2 is now available • Time to start up a gdb-linaro based on that • Matthias mentioned that we will have GDB 7.2 on Maverick • How should we manage the source □ QEMU is over git □ Could use bzr or git □ bzr with Launchpad can't handle multiple branches when pulling from git □ GDB is unique in how it's mixed in with the rest of the projects hosted on sourceare □ Branches as such are trucky □ Could just base off tarballs □ ACTION: Michael to set up a GDB 7.2 based off the release tarball Tickets: • ACTION: Andrew to pull sync changes back into 4.4 for this release • ACTION: Michael to assign appropriate sync ticket to Andrew to track the backport • ACTION: Andrew to merge the current post 4.4.4 release branch into our 4.4 for this release • ACTION: Julian to do a basic investigation into 629671 • ACTION: Andrew to merge the cross-compile objdump ticket into this release and re-kick upstream process Patch tracker: • Andrew noted that it is now fully populated with the GCC data • Has assigned various patches that still need to go upstream to Yao and Julian Next meeting is on 2010-09-08 on the public code. --- Chung-Lin Tang == Linaro Toolchain == * Google ARM patch sets: committed a second set to SG++ 4.5 trunk on Tues. AndrewS pushed both sets to Linaro. Worked on a third set, those related to PR42235, but this time regression test results were not so clean. Will look into, but considering whether to stop the backports here. * LP:628526, submitted a patch to gcc-patches for explicitly turning off stack protection in libgcc build flags, awaiting response. * LP:601030, eglibc 2.11/12 problem with ___longjmp_chk on x86-64. Problem seems to be clear, fix quite simple, but so far cannot seem to reproduce and verify. Also unclear if I should send the fix to eglibc or glibc, the idea of the latter making me a bit nervous... :P == libffi == * Got an acknowledgement from the libffi maintainer that he'll review the VFP hard-float support patch soon. == This week == * Look into remaining Google approved patches, mainly those related to PR42235 and PR42575. * Try to reproduce LP:601030 and send patch soon. * Linaro GCC investigations. --- Andrew Stubbs == Linaro GCC == * Michael has get the new patch tracker into a usable state. I've transferred all the data from the old wiki tracker, and looked up the remaining data as far as I can. The new tracker should now be fully populated with data. It's here, for the moment: http://ex.seabright.co.nz/helpers/patchtrack * Start Yao and Julian on the optimization investigation tasks. * Continue trawl through the CS bugs looking for candidates to push to the Linaro tracker. == Other == * Public holiday on Monday. * Attended the monthly CS/Linaro sync meeting. --- Yao Qi == Linaro GDB wrap up == * LP:615993 gdb.base/sigstep.exp failures Patch was committed to gdb mainline and 7.2 branch. * LP:615995 gdb.base/watch-vfork.exp failures Discussed with Pedro, create a patch, which fixed failures on ARM, but can't fix failures on x86(they are caused by different problems). Leave the x86 failures there, and patch is being reviewed in gdb-patches. == Linaro GCC == * CS306:Investigate on thumb2 improvement Read/understand previous effort related on code size improvement from CSL wiki pages. Experiment with CSL scripts for size benchmarking. With Dan's help, run benchmarking in a correct/reasonable way. 'Reproduce' some inefficient code mentioned by Julian. Some of them are still there. == Misc == * LP:605042 Revert one patch, and rebuild it. No seg fault is found. == This Week == * Continue my work on CS306. --- Peter Maydell RAG: Red: Amber: virtio-system writeup not going as fast as expected Green: ARM legal OK now received Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | ? | | I need to replan this (no forward progress this week because more important stuff intervened) Progress: virtio-system: - actually trying a SATA disk revealed that the PB926 PCI interrupt mapping was wrong; now fixed after consulting the schematics and a round or two of patch testing with Arnd - I have a PB1176 board but it doesn't seem to talk to the serial port on poweron. Will try a firmware reflash but it might just be broken... - no progress on writeup because other things intervened. valgrind: - went through the motions of getting a valgrind svn snapshot into the ubuntu packaging - tested on pegatron (A8, maverick, thumb2), found four bugs: + BX PC not implemented (fixed upstream) https://bugs.kde.org/show_bug.cgi?id=249775 + RBIT not implemented (fixed upstream) https://bugs.kde.org/show_bug.cgi?id=249924 + pwrite64 syscall not implemented (fixed upstream) https://bugs.kde.org/show_bug.cgi?id=249996 + test for presence of neon wrong https://bugs.kde.org/show_bug.cgi?id=249775 With a bodge for the last and the fixes for the first 3, valgrind now successfully runs openoffice and firefox. other: - Investigated https://bugs.launchpad.net/bugs/628471 : qemu-maemo doesn't work with new linaro beagleboard kernels. It looks like we now try to probe for NAND (which failed earlier for other reasons which I suspect are a now-fixed bug), and qemu-maemo's NAND implementation doesn't map anything at the address the nand code is trying to poll for a status bit. - first post to qemu-devel :-) (review of somebody's patch to not confuse SMC with BKPT in the arm decoder) Plans: virtio-system: - hoping to get the qemu patches into the ubuntu qemu-maemo package, which will avoid the need to talk about patching qemu - finish the writeup and put it on the wiki - test PCI patches on PB1176 valgrind: - respin a valgrind with proper fixes for everything and put it in a PPA somewhere other: - come up with some fix or workaround for #628471 - put the rebased ubuntu qemu-maemo work up onto gitorious so other people can see it Absences: Friday 5 November and 20 other days in this calendar year

15 years, 4 months

1
0
0 0

Re: Patch tracker

by Michael Hope

Looks good. I've created a real project, added a README/LICENSE, and merged your changes. See: https://launchpad.net/tcwg-web There was a funny render difference between Firefox and Chromium - revisions with no bugs lead to a rowspan of zero which Firefox doesn't like. I also pulled some common code out into a function and used the built-in variable 'loop'. 'loop' is quite nice as it provides values like .index, .first, .odd, and so on based on your position in the loop. -- Michael On Fri, Sep 3, 2010 at 11:02 PM, Andrew Stubbs <ams(a)codesourcery.com> wrote: > Hi Michael, > > I've been playing with you patch tracker, and come up with this: > > https://code.launchpad.net/~ams-codesourcery/+junk/tcwg-web > > I don't seem to be able to propose an official merge request to your branch, > but it's just a quick implementation anyway, and could probably be cleaned > up. > > The patch renders each ticket in it's own row (without changing the way the > first two columns are rendered). This means they can have their own colour > and we can maybe see better what status goes with what bug. > > To see an example of what it does, see revision 4.4:93544 > > Andrew >

15 years, 4 months

1
0
0 0

State of cross compiler packages

by Marcin Juszkiewicz

I want to share status of my cross compiler packages work with all of you. Some time ago I did a split of them into two: - armel-cross-toolchain-base (1.36 now) - armel-cross-toolchain (1.29 now) Where first one provides binutils, linux headers, libc6 and libgcc packages. Second provides final gcc. Today I got a-c-t-base to a moment when it builds fine on PPA [1]. 1.36 got sent for rebuild to fix missing gcc-4.5-arm-linux-gnueabi-base package. When it will build then a-c-toolchain package will get uploaded for build. Result will deprecate my current repository at people.canonical.com [2] because PPA gives signed repository. On Monday I will probably have to update both components because there was gcc-4.4 upload so probably gcc-4.5 will follow (so I will be able to drop one patch). Additionally I made 'gcc-defaults-armel-cross' package (available in [1]) which makes installing of cross compilers a bit easier (no need to worry which version to install - just "apt-get install gcc-arm-linux-gnueabi" is enough). Selection of cross gcc version is done in other way then native one. Native is using "gcc" package which contains /usr/bin/gcc as symlink to /usr/bin/gcc-4.4 file. Cross gcc uses "update-alternatives" to setup /usr/bin/arm-linux- gnueabi-gcc file. I want to fix it in 11.04 so cross gcc will use same method as native one. 1. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler 2. http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 4 months

2
1
0 0

GDB 7.2 released

by Ulrich Weigand

Michael, a quick update to our discussion today: actually, GDB 7.2 has already been released earlier today: http://sourceware.org/ml/gdb-announce/2010/msg00003.html 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

15 years, 4 months

1
0
0 0

Re: Glibc 2.12 issue

by Michael Hope

Hi Alexander. I've looked into the problem and the linker error is caused by a mix of stack protector options between libgcc and the C library. GCC includes a feature called the stack smashing protector which detects writing past the end of a stack based object. It's quite nice as it gives decent protection against buffer overruns which are the most common type of security vulnerability. The implementation is straight forward: when compiled with -fstack-protector, any function with a stack-based character array will have extra stack checking code inserted into the prologue and epilogue. The prologue allocates a canary value at the top of stack and fills it in with the value of '__stack_chk_guard' provided by libssp. The epilogue checks this value and calls `__stack_chk_fail` if it has been changed. The stack protector can interfere with some code and isn't applicable in others. The problem here is caused by a stack up of things: * glibc knows about -fstack-protector and turns it on and off for different functions and libraries * gcc knows about -fstack-protector and includes libssp if required * glibc knows about libgcc and statically links against it to ensure availability * Meego seems to turn on -fstack-protector by default (as does Ubuntu) This results in the libgcc function '_gcc_Unwind_Backtrace' being built with the stack protector and the glibc library 'libanl' without. At static link time GCC sees that the stack protector is off and skips linking against libssp, causing the missing symbol error. The solution is to add -fno-stack-protector to the libgcc build options and rebuild the compiler. I've heard (but can't track down the link) that the ARM libgcc unwind functions must be built this way in any case. See http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-d… for how Debian does this. Hope that helps, -- Michael On Fri, Aug 27, 2010 at 9:06 PM, <Alexander.Kanevskiy(a)nokia.com> wrote: > Hi Michael. > > I've created for you account in MeeGo OBS (build system that we use in MeeGo > is OpenSuSE build system) > > login: michaelh > password: wog-feg-da > Web client url: https://build.meego.com > API url: https://api.meego.com > > The build log that had problem with glibc 2.12 + gcc 4.5 you can find here: > > https://build.meego.com/package/live_build_log?arch=armv7el&package=glibc&pr > oject=home%3Akad%3Abranches%3ATrunk%3ATesting&repository=standard > > Might be you have some idea what went wrong, as our toolchain people were > not able to find why combination of latest gcc plus glibc 2.11.x works, but > not gcc 4.5 + glibc 2.12.0 :( > > This log is from my home project inside OBS, where stuff is already a bit > outdated. I'll ask Jan-Simon from Linux Fundation to point to right place > where latest builds are present, so you can experiment with them. > > -- > Best regards, Alexander Kanevskiy. > > >

15 years, 4 months

4
6
0 0

Ubuntu GCC version numbers

by Andrew Stubbs

Hi all, I've just discovered that Ubuntu is not using the Linaro release information in the --version string. This is not ideal when we get bug reports as it makes it hard to understand what Linaro release to use to reproduce the issue. Therefore, I've created a new wiki page to track the mappings: https://wiki.linaro.org/WorkingGroups/ToolChain/VersionMappings For now this only applies to GCC, but no doubt other tools will follow. Please help keep it up to date if you find a version is missing. I've added it to the GCC release process wiki page, so hopefully it should get looked at at least once a month. Andrew

15 years, 4 months

2
2
0 0

Versatile Express board

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

15 years, 4 months

2
2
0 0

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

15 years, 4 months

1
0
0 0

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.

15 years, 5 months

1
0
0 0

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.

15 years, 5 months

1
0
0 0

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

15 years, 5 months

3
9
0 0

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 >

15 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain