- linaro-toolchain - lists.linaro.org

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

16 years, 1 month

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. > > >

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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.

16 years, 1 month

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.

16 years, 1 month

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

16 years, 1 month

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 >

16 years, 1 month

1
0
0 0

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

16 years, 1 month

2
1
0 0

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.

16 years, 1 month

3
4
0 0

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

16 years, 1 month

1
0
0 0

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

16 years, 1 month

1
0
0 0

Toolchain WG - 2010-08-12 Standup notes

by Michael Hope

...are here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-11 -- Michael Attendees • Name Email IRC Nick Yao Qi yao.qi(a)linaro.org yao Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw Peter Maydell peter.maydell(a)linaro.org pm215 Michael Hope michael.hope(a)linaro.org michaelh Julian Brown julian(a)codesourcery.com jbrown Chung-Lin Tang cltang(a)codesourcery.com cltang Agenda • Stand up call Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • ACTION: Michael to email his configure options to Julian • ACTION: Richard, if he's going, will set up Action Items from Previous Meeting Minutes • Julian □ Continues to merge 4.4 into the CSL 4.5 branch □ Andrew is pushing changes out to the Linaro branch □ Can't reproduce some failures □ ACTION: Michael to email his configure options to Julian • Ulrich □ Has been ticketing the GDB features and faults for him and Yao to work on • Yao □ GCC patch has been approved upstream □ Going through the GDB tickets • Chung-Lin □ Doing some last optimisations □ Preparing to send the patch upstream • Peter □ Looking into virtio □ Amit has been working on similar □ Michael suggests getting on IRC and asking □ Almost has approval to work publicly • Richard □ Issues were found with the sync fixes. These are being reworked • Michael □ Looked at benchmarks and string routines □ Want the group to start pulling the A9 changes down □ And other A9 pipeline changes □ Richard suggests pulling Marcus's 4.4 sync primitives fix in too • GCC Summit □ Overlaps with UDS □ Ulrich suggests a BoF session on the ARM toolchain □ ACTION: Richard, if he's going, will set up □ Not enough material for a paper at the moment The next meeting is the stand up call on Friday.

16 years, 1 month

2
1
0 0

should linaro-toolchain be listed on GettingInvolved?

by Peter Maydell

I wanted to point somebody at this mailing list (linaro-toolchain), and I noticed that it wasn't listed here: https://wiki.linaro.org/GettingInvolved which is the first place I tried. Is that deliberate, or just an oversight? thanks -- Peter Maydell

16 years, 1 month

2
1
0 0

2010-08-09 Agenda

by Michael Hope

The agenda for today's meeting is available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-09 Note the new conference code. # Review action items from last meeting # New public call-in number: code 263 441 7169 # Release status 4.4 at http://ex.seabright.co.nz/build/gcc-linaro-4.4-2010.08-0/ 4.5 at http://ex.seabright.co.nz/build/gcc-linaro-4.5-2010.08-0/ Ubuntu toolchain would prefer 4.5.1 # Next focus * Merging patches upstream * Prioritising GDB features # Future focus * Emphasise performance, neutral on correctness * Topics to investigate o Vectoriser o Pipeline o PGO o Upstream research topics * Topics for UDS * Benchmarks -- Michael

16 years, 1 month

2
1
0 0

GDB features and bugfixes

by Ulrich Weigand

Hi Michael, here's a list of features and bugfixes that can serve as a basis for Monday's discussion on what we should be working on in GDB in the future. The goal of the list is to fix currently known problems with GDB, including the testsuite, as well as bringing GDB on ARM in line with other platforms by adding required back-end support to enable common GDB features that are already supported elsewhere. It does not yet include anything completely new that we'd develop specifically for ARM. If anybody knows of a feature or bugfix I've missed, please let me know! Features/fixes involving kernel support: - hardware watchpoint support - Neon registers in core files - Interrupted syscall handling - PTRACE_ATTACH disabled ? Features/fixes involving GCC support: - backtrace from abort (missing LR save) - debug info for args in varargs routine GDB features/fixes: - prologue parsing on Thumb-2 - displaced stepping on Thumb - syscall tracing support - improved epilogue detection (fix software watchpoints) - multi-threaded debugging inferior crashes - multi-threaded Thumb/ARM state tracking - signal handler stepping - inferior call fixes - misc. other testsuite regressions gdbserver features/fixes - Neon register support - fast tracepoints 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

16 years, 1 month

2
2
0 0

Toolchain WG - 2010-08-07 Standup notes

by Michael Hope

= Friday 7th August 2010 = == This month's meetings == <<MonthCalendar(WorkingGroups/ToolChain/Meetings,2010,08,,,,WorkingGroups/ToolChain/MeetingTemplate)>> == Attendees == ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Name ||<style="text-align: center;">Email ||<style="text-align: center;">IRC Nick || || Andrew Stubbs || andrew.stubbs(a)linaro.org || ams || || Chung-Lin Tang || cltang(a)codesourcery.com || cltang || || Julian Brown || julian(a)codesourcery.com || jbrown || || Marcin Juszkiewicz || marcin.juszkiewicz(a)linaro.org || hrw || || 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.qi(a)linaro.org || yao || == Agenda == * Stand up meeting == Action Items from this Meeting == == Action Items from Previous Meeting == == Minutes == * Andrew: * Continues to push the 4.5 patches * Seen one regression so far which he is investigating * Continues to approve 4.4 merge requests * Spinning 2010.08 release today * Will give tarball to michaelh to also build * Yao: * Continuing on bug fixes and merges * [[LP:602174]]: Problem has gone away, to confirm on release * [[LP:602288]]: Leave test in-place. Change was backed out * [[LP:602190]]: will set options in test case * Ulrich: * Investigating test failures * getfem++ failure is triggered in wrapped library * May be due to a different environment * Will investigate further * Richard: * Cortex-A9 patches sent upstream (http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00481.html) * `__sync` primitive patches sent upstream (http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00492.html) * Peter * Introduced himself * Julian: * Porting patches from 4.4 to the 4.5 CSL branch is ongoing * Continuing with the misalignment patch issues * Looking into failures on the 4.5 CSL branch * Michael asked Julian to look at the 4.5 tests on Linaro as well * Marcin: * All stages of the cross compiler are done * Sent a link to the PPA over IRC * Mentioned that configure objcopy issue. Michael says that the TCWG will take it over * Vacation is coming up in about a week * Chung-Lin: * Now running the libffi test suite * Four regressions so far * Andrew is organising access to the benchmark suite * Michael: do want to be able to reproduce these results in the future. Please record everything needed to reproduce (compiler, host, environment, scripts, etc.) * Michael: * Extending the builds further. Added eglibc. * Thinking about what's next * Discuss on Monday

16 years, 1 month

1
0
0 0

Conference code for Monday

by Michael Hope

Monday's call will be on conference code 263 441 7169. The dial-in numbers are the usual Canonical numbers listed here: https://docs.google.com/Doc?id=af8g8fcnf79_498dfz9v9fv -- Michael

16 years, 1 month

1
0
0 0

LP:602190 & LP:602285

by Yao Qi

LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are related to this patch below. You can get more details from comments of these bugs, since I've added my understand of the cause in comments. This patch is to improve the performance of generated code, however, these two bugs are related to this patch(, correct me if I am wrong). Now, we have two options, 1) revert this patch, and make these test case pass; 2) keep this patch and fix test cases, 3) fix bugs and keep this patch, What do you think? 2009-08-26 Daniel Jacobowitz <dan(a)codesourcery.com> Issue #6131 - Enable additional optimizations by default in Lite Issue #6103 - Reduce default unrolling parameters at -O3 * release-notes-csl.xml (Improved optimization for ARM): New note. gcc/ * config/arm/arm.c (arm_override_options): If flag_unroll_loops has the default value, adjust unrolling parameters. (arm_optimization_options): Set flag_unroll_loops to a default value. Enable flag_promote_loop_indices. Modified: gcc/config/arm/arm.c ============================================================================== --- gcc/config/arm/arm.c (original) +++ gcc/config/arm/arm.c Fri Aug 28 14:41:19 2009 @@ -55,6 +55,7 @@ #include "langhooks.h" #include "df.h" #include "intl.h" +#include "params.h" /* Forward definitions of types. */ typedef struct minipool_node Mnode; @@ -1857,6 +1858,29 @@ warning (0, "-low-irq-latency has no effect when compiling for the Thumb"); low_irq_latency = 0; + } + + /* CSL LOCAL */ + /* Loop unrolling can be a substantial win. At -O2, limit to 2x + unrolling by default to prevent excessive code growth; at -O3, + limit to 4x unrolling by default. We know we are not optimizing + for size if this is set (see arm_optimization_options). */ + if (flag_unroll_loops == 2) + { + if (optimize == 2) + { + flag_unroll_loops = 1; + if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES)) + set_param_value ("max-unroll-times", 2); + } + else if (optimize > 2) + { + flag_unroll_loops = 1; + if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES)) + set_param_value ("max-unroll-times", 4); + } + else + flag_unroll_loops = 0; } } @@ -21175,6 +21199,17 @@ set_param_value ("max-inline-insns-single", 1); set_param_value ("max-inline-insns-auto", 1); } + else + { + /* CSL LOCAL */ + /* Set flag_unroll_loops to a default value, so that we can tell + if it was specified on the command line; see + arm_override_options. */ + flag_unroll_loops = 2; + /* Promote loop indices to int where possible. Consider moving this + to -Os, also. */ + flag_promote_loop_indices = 1; + } } -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

16 years, 1 month

3
4
0 0

Initial QEMU work

by Michael Hope

Hi Peter. Further to our call yesterday, I've created four blueprints that cover the initial QEMU work: https://blueprints.launchpad.net/qemu-linaro virtio-system and qemu-focused-kernel should be done first, but you might as well start looking at merge-other-branches in the background. I haven't gone into great detail - feel free to flesh out the blueprints as you go, and don't hesitate to ask if you need more information. -- Michael

16 years, 2 months

1
0
0 0

Multiarch paths and toolchain implications

by Ulrich Weigand

Hi Wookey, I've finally completed a first of draft the write-up of toolchain implications of multiarch paths that we discussed in Prague. Sorry it took a while, but it got a lot longer than I expected :-/ I'd appreciate any feedback and comments! Multiarch paths and toolchain implications == Overview and goals == Binary files in packages are usually platform-specific, that is they work only on the architecture they were built for. Therefore, the packaging system provides platform-specific versions for them. Currently, these versions will install platform-specific files to the same file system locations, which implies that only one of them can be installed into a system at the same time. The goal of the "multiarch" effort is to lift this limitation, and allow multiple platform-specific versions of the same package to be installed into the same file system at the same time. In addition, each package should install to the same file system locations no matter on which host architecture the installation is performed (that is, no rewriting of path names during installation). This approach could solve a number of existing situations that are not handled well by today's packaging mechanisms: - Systems able to run binaries of more than one ISA natively. - Support for multiple incompatible ABI variants on the same ISA. - Support for processor-optimized ABI-compatible library variants. - NFS file system images exported to hosts of different architectures. - Target file systems for ISA emulators etc. - Development packages for cross-compilation. In order to support this, platform-specific versions of a multiarch package must have the property that for each file, it is either 100% identical across platforms, or else it must be installed to separate locations in the file system. The latter is the case at least for executable files, shared libraries, static libraries and object files, and to some extent maybe header files. This means that in a multiarch world, such files must move to different locations in the file system than they are now. This causes a variety of issues to be solved; in particular, most of the existing locations are defined by the LHS and/or are assumed to have well-known values by various system tools. In this document, I want to focus on the impact of file system hierarchy changes to two tasks in particular: - loading/running an executable - building an executable from source In the following two sections, I'll provide details on file system paths are currently handled in these two areas. In the final section, I'll discuss suggestions how to extend the current behavior to support multiarch paths. == Loading/running an executable == Running a new executable starts with the execve () system call. The Linux kernel supports execution of a variety of executable types; most commonly used are - native ELF executable - ELF exectuable for a secondary native ISA (32-bit on 64-bit) - #! scripts - user-defined execution handlers (via binfmt_misc) The binary itself is passed via full (or relative) pathname to the execve call; the kernel does not make file system hierarchy assuptions. By convention, callers of execve ususally search well-known path locations (via the PATH environment variable) when locating executables. How to adapt these conventions for multiarch is beyond the scope of this document. With #! scripts and binfmt_misc handlers, the kernel will involve a user-space helper to start execution. The location of these handlers themselves and secondary files they in turn may require is provided by user space (e.g. in the #! line, or in the parameters installed into the binfmt_misc file system). Again, adapting these path names is beyond the scope of this document. For native ELF executables, there are two additional classes of files involved in the initial load process: the ELF interpreter (dynamic loader), and shared libraries required by the executable. The ELF interpreter name is provided in the PT_INTERP program header of the ELF executable to be loaded; the kernel makes no file name assumptions here. This program header is generated by the linker when performing final link of a dynamically linked executable; it uses the file name passed via the -dynamic-linker argument. (Note that while the linker will fall back to some hard-coded path if that argument is missing, on many Linux platforms this default is in fact incorrect and does not correspond to a ELF interpreter actually installed in the file system in current distributions. Passing a correct -dynamic-linker argument is therefore mandatory.) In normal builds, the -dynamic-linker switch is passed to the linker by the GCC compiler driver. This in turn gets the proper argument to be used on the target platform from the specs file; the (correct) default value is hard-coded into the GCC platform back-end sources. On bi-arch platforms, GCC will automatically choose the correct variant depending on compile options like -m32 or -m64. Again, the logic to do so is hard-coded into the back-end. Unfortunately, various bi-arch platforms use different schemes today: amd64: /lib/ld-linux.so.2 vs. /lib64/ld-linux-x86-64.so.2 ia64: /lib/ld-linux.so.2 vs. /lib/ld-linux-ia64.so.2 mips: /lib/ld.so.1 vs. /lib64/ld.so.1 ppc: /lib/ld.so.1 vs. /lib64/ld64.so.1 s390: /lib/ld.so.1 vs. /lib/ld64.so.1 sparc: /lib/ld-linux.so.2 vs. /lib64/ld-linux.so.2 Once the dynamic interpreter is loaded, it will go on and load dynamic libraries required by the executable. For this discussion, we will consider only the case where the interpreter is ld.so as provided by glibc. As opposed to the kernel, glibc does in fact *search* for libraries, and makes a variety of path name assumptions while doing so. It will consider paths encoded via -rpath, the LD_LIBRARY_PATH environment variable, and knows of certain hard-coded system library directories. It also provides a mechanism to automatically choose the best out of a number of libraries available on the system, depending on which capabilities the hardware / OS provides. Specifically, glibc determines a list of search directory prefixes, and a list of capability suffixes. The directory prefixes are: - any directory named in the (deprecated) DT_RPATH dynamic tag of the requesting object, or, recursively, any parent object (note that DT_RPATH is ignored if DT_RUNPATH is also present) - any directory listed in the LD_LIBRARY_PATH environment variable - any directory named in the DT_RUNPATH dynamic tag of the requesting object (only) - the system directories, which are on Linux hard-coded to: * /lib$(biarch_suffix) * /usr/lib$(biarch_suffix) where $(biarch_suffix) may be "64" on 64-bit bi-arch platforms. The capability suffixes are determined from the following list of capabilities: - For each hardware capability that is present on the hardware as indicated by a bit set in the AT_HWCAP auxillary vector entry, and is considered "important" according to glibc's hard-coded list of important hwcaps (platform-dependent), a well-known string provided by glibc's platform back-end. - For each "extra" hardware capability present on the hardware as indicated by a GNU NOTE section in the vDSO provided by the kernel, a string provided in that same note. - A string identifying the platform as a whole, as provided by the kernel via the AT_PLATFORM auxillary vector entry. - For each software capability supported by glibc and the kernel, a well-known string. The only such capability supported today is "tls", indicating support for thread-local storage. The full list of capability suffixes is created from the list of supported capabilities by forming every sub-sequence. For example, if the platform is "i686", supports the important hwcap "sse2" and TLS, the list of suffixes is: sse2/i686/tls sse2/i686 sse2 i686/tls i686 tls <empty> The total list of directories to be searched is then formed by concatenating every directory prefix with every capability suffix. Various caching mechanisms are employed to reduce the run-time overhead of this large search space. Note: This method of searching capability suffixes is employed only by glibc at run time; it is unknown to the toolchain at compile time. This implies that an executable will have been linked against the "base" version of a library, and the "capability-specific" version of the library is only substituted at run time. Therefore, all capability-specific versions must be ABI-compatible to the base version, in particular they must provide the same soname and symbol versions, and they must use compatible function calling conventions. == Building an executable from source == For this discussion, we only consider GCC and the GNU toolchain, installed into the usual locations as system toolchain, and in the absence of any special-purpose options (-B) or environment variables (GCC_EXEC_PREFIX, COMPILER_PATH, LIBRARY_PATH ...). However, we do consider the three typical modes of operation: - native compilation - cross-compilation using a "traditional" toolchain install - cross-compilation using a sysroot During the build process, the toolchain performs a number of searches for files. In particular, it looks for (executable) components of the toolchain itself; for include files; for startup object files; and for static and dynamic libraries. In doing so, the GNU toolchain considers locations derived from any of the following "roots": - Private GCC installation directories * /usr/lib/gcc * /usr/libexec/gcc These hold both GCC components and target-specific headers and libraries provided by GCC itself. - GNU toolchain installation directories * /usr/$(target) These directories hold files used across multiple components of the GNU toolchain, including the compiler and binutils. In addition, they may also hold target libraries and headers; in particular for libraries traditionally considered part of the toolchain, like newlib for embedded systems. In fact, in the "traditional" installation of a GNU cross-toolchain, *all* default target libraries and headers are found here. However, the toolchain directories are always consulted for native compilation as well (if present)! - The install "prefix" This is what is specified via the --prefix configure option. The toolchain will look for headers and libraries under that root, allowing for building and installing of multiple software packages that depend on each other into a shared prefix. (This is really only relevant when the toolchain is *not* installed as system toolchain, e.g. in a setup where you provide a GNU toolchain + separately built GNU packages on a non-GNU system in some distinct non-system directory.) - System directories * /lib$(biarch_suffix) * /usr/lib$(biarch_suffix) * /usr/local/lib$(biarch_suffix) * /usr/include * /usr/local/include These are default locations defined by the OS and hard-coded into the toolchain sources. The examples above are those used for Linux. On bi-arch platforms, $(biarch_suffix) may be the suffix "64". These directories are used only for native compilation; however in a "sysroot" cross-compiler, they are used for cross-compilation as well, prefixed by the sysroot directory. In addition to the base directory paths refered to above, the GNU toolchain supports the so-called "multilib" mechanism. This is intended to provide support for multiple incompatible ABIs on a single platform. This is implemented by the GCC back-end having hard-coded information about which compiler option causes an incompatible ABI change, and a hard-coded "multilib" directory suffix name corresponding to that option. For example, on PowerPC the -msoft-float option is associated with the multilib suffix "nof", which means libraries using the soft-float ABI (passing floating point values in integer registers) can be provided in directories like: /usr/lib/gcc/powerpc-linux/4.4.4/nof /usr/lib/nof The multilib suffix is appended to all directories searched for libraries by GCC and passed via -L options to the linker. The linker itself does not have any particular knowledge of multilibs, and will continue to consult its default search directories if a library is not found in the -L paths. If multiple orthogonal ABI-changing options are used in a single compilation, multiple multilib suffixes can be used in series. As a special consideration, some compiler options may correspond to multiple incompatible ABIs that are already supported by the OS, but using directory names differently from what GCC would use internally. As the typical example, on bi-arch systems the OS will normally provide the default 64-bit libraries in /usr/lib64, while also providing 32-bit libraries in /usr/lib. For GCC on the other side, 64-bit is the default (meaning no multilib suffix), while the -m32 option is associated with the multilib suffix "32". To solve this problem, the GCC back-end may provide a secondary OS multilib suffix which is used in place of the primary multilib suffix for all library directories derived from *system* paths as opposed to GCC paths. For example, in the typical bi-arch setup, the -m32 option is associated with the OS multilib suffix "../lib". Given the that primary system library directory is /usr/lib64 on such systems, this has the effect of causing the toolchain to search /usr/lib64/gcc/powerpc64-linux/4.4.4 /usr/lib64 for default compilations, and /usr/lib64/gcc/powerpc64-linux/4.4.4/32 /usr/lib64/../lib (i.e. /usr/lib) for -m32 compilations. The following rules specify in detail which directories are searched at which phase of compilation. The following parameters are used: $(target) GNU target triple (as specified at configure time) $(version) GCC version number $(prefix) Determined at configure time, usually /usr or /usr/local $(libdir) Determined at configure time, usually $(prefix)/lib $(libexecdir) Determined at configure time, usually $(prefix)/libexec $(tooldir) GNU toolchain directory, usually $(prefix)/$(target) $(gcc_gxx_include_dir) Location of C++ header files. Determined at configure time: * If --with-gxx-include-dir is given, the specified directory * Otherwise, if --enable-version-specific-runtime-libs is given: $(libdir)/gcc/$(target)/$(version)/include/c++ * Otherwise for all cross-compilers (including with sysroot!): $(tooldir)/include/c++/$(version) * Otherwise for native compilers: $(prefix)/include/c++/$(version) $(multi) Multilib suffix appended for GCC include and library directories $(multi_os) OS multilib suffix appended for system library directories $(sysroot) Sysroot directory (empty for native compilers) Directories searched by the compiler driver for executables (cc1, as, ...): 1. GCC directories: $(libexecdir)/gcc/$(target)/$(version) $(libexecdir)/gcc/$(target) $(libdir)/gcc/$(target)/$(version) $(libdir)/gcc/$(target) 2. Toolchain directories: $(tooldir)/bin/$(target)/$(version) $(tooldir)/bin Directories searched by the compiler for include files: 1. G++ directories (when compiling C++ code only): $(gcc_gxx_include_dir) $(gcc_gxx_include_dir)/$(target)[/$(multi)] $(gcc_gxx_include_dir)/backward 2. Prefix directories (if distinct from system directories): [native only] $(prefix)/include 3. GCC directories: $(libdir)/gcc/$(target)/$(version)/include $(libdir)/gcc/$(target)/$(version)/include-fixed 4. Toolchain directories: [cross only] $(tooldir)/sys-include $(tooldir)/include 5. System directories: [native/sysroot] $(sysroot)/usr/local/include [native/sysroot] $(sysroot)/usr/include Directories searched by the compiler driver for startup files (crt*.o): 1. GCC directories: $(libdir)/gcc/$(target)/$(version)[/$(multi)] 2. Toolchain directories: $(tooldir)/lib/$(target)/$(version)[/$(multi_os)] $(tooldir)/lib[/$(multi_os)] 3. Prefix directories: [native only] $(libdir)/$(target)/$(version)[/$(multi_os)] [native only] $(libdir)[/$(multi_os)] 4. System directories: [native/sysroot] $(sysroot)/lib/$(target)/$(version)[/$(multi_os)] [native/sysroot] $(sysroot)/lib[/$(multi_os)] [native/sysroot] $(sysroot)/usr/lib/$(target)/$(version)[/$(multi_os)] [native/sysroot] $(sysroot)/usr/lib[/$(multi_os)] Directories searched by the linker for libraries: In addition to these directories built-in to the linker, if the linker is invoked via the compiler driver, it will also search the same list of directories specified above for startup files, because those are implicitly passed in via -L options by the driver. Also, when searching for dependencies of shared libraries, the linker will attempt to mimic the search order used by the dynamic linker, including DT_RPATH/DT_RUNPATH and LD_LIBRARY_PATH lookups. 1. Prefix directories (if distinct from system directories): [native only] $(libdir)$(biarch_suffix) 2. Toolchain directories: [native/cross] $(tooldir)/lib$(biarch_suffix) 3. System directories: [native/sysroot] $(sysroot)/usr/local/lib$(biarch_suffix) [native/sysroot] $(sysroot)/usr/lib$(biarch_suffix) [native/sysroot] $(sysroot)/lib$(biarch_suffix) 4. Non-biarch directories (if distinct from the above) [native only] $(libdir) [native/cross] $(tooldir)/lib [native/sysroot] $(sysroot)/usr/local/lib [native/sysroot] $(sysroot)/usr/lib [native/sysroot] $(sysroot)/lib == Multiarch impact on the toolchain == The current multiarch proposal is to move the system library directories to a new path including the GNU target triplet, that is, instead of using /lib /usr/lib the system library directories are now called /lib/$(multiarch) /usr/lib/$(multiarch) At this point, there is no provision for multiarch executable or header file installation. What are the effects of this renaming on the toolchain, following the discussion above? * ELF interpreter The ELF interpreter would now reside in a new location, e.g. /lib/$(multiarch)/ld-linux.so.2 This allows interpreters for different architectures to be installed simultaneously, and removes the need for the various bi-arch hacks. Change would imply modification of the GCC back-end, and possibly the binutils ld default as well (even though that's currently not normally used), to build new executables using the new ELF interpreter install path. Caveats: Any executable built with the new ELF interpreter will absolutely not run on a system that does not provide the multiarch install location of the interpreter. (This is probably OK.) Executables built with the old ELF interpreter will not run on a system that *only* provides the multiarch install location. This is clearly *not* OK. To provide backwards compatibility, even a multiarch-capable system will need to install ELF interpreters at the old locations as well, possibly via symlinks. (Note that any given system can only be compatible in this way with *one* architecture, except for lucky circumstances.) As the multiarch string $(multiarch) is now embedded into each and every executable file, it becomes invariant part of the platform ABI, and needs to be strictly standardized. GNU target triplets as used today in general seem to provide too much flexibility and underspecified components to serve in such a role, at least without some additional requirements. * Shared library search paths According to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string: * /lib/$(multiarch) * /usr/lib/$(multiarch) This requires modifications to glibc's ld.so loader (can possibly be provided via platform back-end changes). Backwards compatibility most likely requires that both the new multiarch location and the old location are searched. Open questions: + How are -rpath encoded paths to be handled? Option A: They are used by ld.so as-is. This implies that in a fully multiarch system, every *user* of -rpath needs to update their paths to include the multiarch target. Also, multiarch targets are once again directly embedded into exectuables. Option B: ld.so automatically appends the multiarch target string to the path as encoded in DT_RPATH/DT_RUNPATH. This may break backwards compatibility. Option C: ld.so searches both the -rpath as is, and also with multiarch target string appended. + How is LD_LIBRARY_PATH to be handled? The options here are basically analogous to the -rpath case. + What is the interaction between the multiarch string and capability suffixes (hwcaps etc.) supported by ld.so? The most straightforward option seems to be to just leave the capability mechanism unchanged, that is, ld.so would continue to append the capabitility suffixes to all directory search paths (which potentially already include a multiarch suffix). This implies that different ABI-compatible but capability-optimized versions of a library share the same multiarch prefix, but use different capability suffixes. * GCC and toolchain directory paths The core multiarch spec only refers to system directories. What about directories provided by GCC and the toolchain? Note that for a cross-development setup, we may have various combinations of host and target architectures. In this case $(host-multiarch) refers to the multiarch identifier for the host architecture, while $(target-multiarch) refers to the one for the target architecture. In addition $(target) refers to the GNU target triplet as currently used by GCC paths (which may or may not be equal to $(target-multiarch), depending on how the latter will end up being standardized). + GCC private directories The GCC default installation already distinguishes files that are independent of the host architecture (in /usr/lib/gcc) from those that are dependent on the host architecture (in /usr/libexec/gcc). In both cases, the target architecture is already explicitly encoded in the path namess. Thus it would appear that we'd simply have to move the libexec paths to include the multiarch string in a straightforward manner in order: /usr/lib/gcc/$(target)/$(version)/... /usr/libexec/$(host-multiarch)/gcc/$(target)/$(version)/... This assumes that two cross-compilers to the same target running on different hosts can share /usr/lib/gcc, which may not be fully possible (because two cross-compilers may build slightly different versions of target libraries due to optimization differences). In this case, the whole of /usr/lib/gcc could be moved to multiarch as well: /usr/lib/$(host-multiarch)/gcc/$(target)/$(version)/... /usr/libexec/$(host-multiarch)/gcc/$(target)/$(version)/... The alternative would be to package them separately, with the host independent files always coming from the same package (presumbly itself produced on a native system, or else one "master" host system). Note that if -in the first stage of multiarch- we do not support parallel installation of *binaries*, we may not need to do anything for the GCC directories. + Toolchain directories The /usr/$(target) directory used by various toolchain components is somewhat of a mixture of target vs. host dependent files: /usr/$(target)/bin executable files in host architecture, targeting target architecture (e.g. cross-assembler, cross-linker binaries) /usr/$(target)/sys-include target headers (only for cross-builds) /usr/$(target)/include native toolchain header files for target (like bfd.h) /usr/$(target)/lib target libraries + native toolchain libraries for target (like libbfd.a) /usr/$(target)/lib/ldscripts linker scripts used by the cross-linker In a full multiarch setup, the only directory that would require the multiarch suffix is probably bin: /usr/$(target)/bin/$(host-multiarch) As discussed above, if we want to support different versions of target libraries for the same target, as compiled with differently hosted cross-compilers, we might also have to multiarch the lib directory: /usr/$(target)/lib/$(host-multiarch) Yet another option might be to require multiarch systems to always use the sysroot cross-compile option, and not support the toolchain directory for target libraries in the first place. [Or at least, have no distribution package ever install any target library into the toolchain lib directory ...] + System directories For these, the primary multiarch rules would apply. In a sysroot configuration, the sysroot prefix is applied as usual (after the multiarch paths have been determined as for a native system). Note that we need to apply the *target* multiarch string here; in case this is different from the target triplet, the toolchain would have to have explicit knowledge of those names: /lib/$(target-multiarch) /usr/lib/$(target-multiarch) + Prefix directories For completeness' sake, we need to define how prefix directories are handled in a GCC build that is both multiarch enabled *and* not installed into the system prefix. The most straightforward solution would be to apply multiarch suffixes to the prefix directories as well: $(prefix)/lib/$(target-multiarch) $(prefix)/include/$(target-multiarch) [ if include is multiarch'ed ... ] * Multiarch and cross-compilation Using the paths as discussed in the previous section, we have some options how to perform cross-compilation on a multiarch system. The most obvious option is to build a cross-compiler with sysroot equal to "/". This means that the compiler will use target libraries and header files as installed by unmodified distribution multiarch packages for the target architecture. This should ideally be the default cross-compilation setup on a multi-arch system. In addition, it is still possible to build cross-compilers with a different sysroot, which may be useful if you want to install target libraries you build yourself into a non-system directory (and do not want to require root access for doing so). Questions: + Should we still support "traditional" cross-compilation using the toolchain directory to hold target libraries/header This is probably no longer really useful. On the other hand, it probably doesn't really hurt either ... + What about header files in a multiarch system? The current multiarch spec does not provide for multiple locations for header files. This works only if headers are identical across all targets. This is usually true, and where it isn't, can be enforced by use of conditional compilation. In fact, the latter is how things currently work on traditional bi-arch distributions. In the alternative, the toolchain could also provide for multiarch'ed header directories along the lines of /usr/include/local/$(target-multiarch) /usr/include/$(target-multiarch) which are included in addition to (and before) the usual directories. It will most likely not be necessary to do this for the GCC and toolchain directory include paths, as they are already target-specific. * Multiarch and multilib The multilib mechanism provides a way to support multiple incompatible ABI versions on the same ISA. In a multiarch world, this is supposed to be handled by different multiarch prefixes, to enable use of the package management system to handle libraries for all those variants. How can we reconcile the two systems? It would appear that the way forward is based on the existing "OS multilib suffix" mechanism. GCC already expects to need to handle naming conventions provided by the OS for where incompatible versions are to found. In a multiarch system, the straightforward solution would appear to be to use the multiarch names as-is as OS multilib suffixes. In fact, this could even handle the *default* multiarch name without requiring any further changes to GCC. For example, in a bi-arch amd64 setup, the GCC back-end might register "x86_64-linux" as default OS multilib suffix, and "i386-linux" as OS multilib suffix triggered by the (ABI changing) -m32 option. Without any further change, GCC would now search /usr/lib/x86_64-linux or /usr/lib/i386-linux as appropriate, depending on the command line options used. (This assumes that the main libdir is /usr/lib, i.e. no bi-arch configure options were used.) Note that GCC would still use its own internal multilib suffixes for its private libraries, but that seems to be OK. Caveat: This would imply those multilib names, and their association with compiler options, becomes hard-coded in the GCC back-end. However, this seems to have already been necessary (see above). == Summary == >From the preceding discussion, it would appear a multiarch setup allowing parallel installation of run-time libraries and development packages, and thus providing support for running binaries of different native ISAs and ABI variants as well as cross-compilation, might be feasible by implementing the following set of changes. Note that parallel installation of main *executable* files by multiarch packages is not (yet) supported. * Define well-known multiarch suffix names for each supported ISA/ABI combination. Well-known in particular means it is allowed for them to be hard-coded in toolchain source files, as well as in executable files and libraries built by such a toolchain. * Change GCC back-ends to use the well-known multiarch suffix as OS multilib suffix, depending on target and ABI-changing options. Also include multiarch suffix in ELF interpreter name passed to ld. (Probably need to change ld default directory search paths as well.) * Change the dynamic loader ld.so to optionally append the multiarch suffix (as a constant string pre-determined at ld.so build time) after each directory search path, before further appending capability suffixes. (See above as to open questions about -rpath and LD_LIBRARY_PATH.) * Change package build/install rules to install libraries and ld.so into multiarch library directories (not covered in this document). Change system installation to provide for backward-compatibility fallbacks (e.g. symbolic links to the ELF interpreter). * If capability-optimized ISA/ABI-compatible library variants are desired, they can be build just as today, only under the (same) multiarch suffix. They could be packaged either within a single pacakge, or else using multiple packages (of the same multiarch type). * Enforce platform-independent header files across all packages. (In the alternative, provide for multiarch include paths in GCC.) * Build cross-compiler packages with --with-sysroot=/ I'd appreciate any feedback or comments! Have I missed something? 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

16 years, 2 months

5
23
0 0

Bootstrapping cross compiler status

by Marcin Juszkiewicz

As you probably know I am working on bootstrapping cross compiler. Process is described on https://wiki.linaro.org/CrossCompilers page. Current status is: nearly done. Done: - Linux/stage1 - patch (LP:603087) waits approval from kernel team. - GCC 4.5/stage[12] - patch (LP:603497) created In progress: - eglibc/stage1 builds but needs packaging work Problems: - gcc/stage3 (normal full build) fails on shlibs because I do not have libc6-armel packages installed in system but dpkg-shlibdeps needs them How to bootstrap cross compiler? - apt-get source gcc-4.5 eglibc binutils linux-image-2.6.35-8-generic - copy gcc-4.5 dir to gcc-stage1 gcc-stage2 gcc-stage3 - copy eglibc dir to eglibc-stage1 eglibc-stage2 - fetch and apply my patches from LP:603087 LP:603497 LP:603498 - create directory "sysroot/" and point WITH_SYSROOT and WITH_BUILD_SYSROOT enviroment variables to it - cd binutils* && TARGET=armel dpkg-buildpackage -b -uc -us - cd sysroot && dpkg-deb -x ../binutils-arm*deb . - export PATH=$PWD/sysroot/usr/bin:$PATH - export LD_LIBRARY_PATH=$PWD/sysroot/usr/x86_64-linux*/usr/arm*/lib - cd linux* && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -aarmel - cd sysroot && dpkg-deb -x ../linux-libc-dev*deb . - cd gcc-stage1 && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us - cd sysroot && dpkg-deb -x ../cpp*deb ../gcc*deb . - cd eglibc-stage1 && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -aarmel As packaging is not yet done for that step manual copying of debian/tmp-libc/ contents to sysroot dir is needed. - cd gcc-stage2 && DEB_STAGE=stage2 dpkg-buildpackage -b -uc -us - cd sysroot && dpkg-deb -x ../cpp*deb ../gcc*deb . - cd eglibc-stage2 && dpkg-buildpackage -b -uc -us -aarmel - cd sysroot && dpkg-deb -x ../libc*deb . - cd gcc-stage3 && dpkg-buildpackage -b -uc -us Here dpkg-shlibdeps will complain so for that step manual copying of debian/tmp/ contents to sysroot dir is needed. sysroot dir will then contain working cross compiler - so far I used it to compile hello.c and kernel for beagleboard I did not tested yet building stage3 compiler with sysroot=/ like it should be for installing it on other systems. But thats future. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

16 years, 2 months

1
1
0 0

gcc-linaro-4.5+bzr99315 build results

by Michael Hope

...are available at: http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99315/ I've also finished reference builds of FSF GCC 4.4.4, 4.5.0, and 4.5.1. According to the GCC testsuite, there are no regressions between the Linaro and FSF branches and in some ways we're a bit better: On x86_64 for FSF 4.5.0 (-) vs linaro-4.5+bzr99315 (+): === gcc Summary === -# of expected passes 61211 +# of expected passes 61239 +# of unexpected successes 1 -# of expected failures 180 +# of expected failures 179 # of unsupported tests 825 On i686 FSF 4.5.0 vs linaro-4.5+bzr99315: === gcc Summary === -# of expected passes 62285 +# of expected passes 62309 # of unexpected failures 12 -# of unexpected successes 25 +# of unexpected successes 26 -# of expected failures 192 +# of expected failures 191 # of unsupported tests 533 g++, fortran, and objc are the same between builds. And, strangely enough, ARM is still building. -- Michael

16 years, 2 months

1
0
0 0

gcc-linaro-4.5+99310

by Michael Hope

Results are available here: http://ex.seabright.co.nz/build/gcc-linaro-4.5-99310/ Colourised versions of the build logs are available at: http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.5-99310/logs/i686-lu… http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.5-99310/logs/x86_64-… http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.5-99310/logs/armv7l-… i686 has # of unexpected failures 12 # of unexpected successes 26 x86_64 has: # of unexpected successes 1 armv7l has: # of unexpected failures 16 # of unexpected successes 2 g++: # of unexpected failures 6 I've started reference builds of FSF 4.4.4 and 4.5.0. i686 is done, x86_64 half done, and armv7l is still soldering along... -- Michael

16 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain