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
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.
...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
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
>
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
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
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.
>
>
>
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
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
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-18https://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
...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.
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.
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
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
>
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
...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.
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
...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
...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.
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
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
= 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
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