Hello, my fellow ARM aficionados!
The Linaro Developer Platform Team is pleased to announce a new initiative
to help improve the state of software on ARM: the ARM porting jam. Starting
today, February 16th, we will be running a weekly IRC jam on Wednesdays from
1400-1800 UTC to bring developers together to work on all manner of
userspace porting bugs, with the aim of fixing portability issues and
getting the fixes delivered to our upstreams.
An initial porting queue of known issues can be found here:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue
Interested in making the software in Ubuntu run better on ARM? Stop on by
the #linaro channel on irc.linaro.org today!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek(a)ubuntu.com vorlon(a)debian.org
"Will Deacon" <will.deacon(a)arm.com> wrote on 02/11/2011 10:13:01 AM:
> I don't have a pandaboard, so I'd be interested to see if the code
> works there. I developed it using ARM boards, so the versatile express
> is a known good target.
I've now got it working reliably on on Versatile Express, after fixing
a couple of bugs on the GDB side (both in the HW-watchpoint patch, and
in common GDB code). The testsuite now passes with no regressions when
enabling HW watchpoints, except for two tests that require more than one
single watchpoint to be supported.
This raises another couple of issues/questions, however:
- In testing on Versatile Express, I noticed what appears to be SMP
related bugs in handling regular software breakpoints: occasionally,
software breakpoints simply are not hit and execution continues as if
the underlying code had not been changed at all. This symptom
completely goes away if GDB and the debugged process are forced to
the same CPU using the affinity feature (e.g. with schedtool).
My guess, just from seeing those symptoms, would be that when inserting
a software breakpoint via ptrace, not all i-caches on all CPUs are
reliably flushed ... Any thoughts on this?
- As mentioned above, the kernel currently only supports one single
watchpoint to be active at a time, even though hardware might support
multiple ones. The reason seems to be that when a watchpoint triggers,
the kernel cannot figure out which one it was (if there's more than one
choice).
This is a bit unfortunate, given that GDB will attempt to insert two
or more watchpoints in many interesting cases (e.g. a "watch *p"
command will insert *two* low-level watchpoints, one at the address
of p, and one at the address where p (currently) points to).
In addition, for regular (write) watchpoints, GDB does not actually
*require* the underlying hardware/kernel to specify which watchpoint
was hit; GDB is able to find out by itself by checking whether the
values at any of the currently active locations actually changed.
(For read/access type watchpoints, GDB does require that underlying
support -- but those are much more rarely used anyway.)
Do you see any chance of improving upon the current behaviour?
- Finally, I noticed when reading kernel code that under some
circumstances, the kernel will automatically do a single step to
get off a watchpoint that was just hit. However, this does not
happen for user-space watchpoints installed via ptrace, right?
(Just wanting to confirm; since GDB currently does that single
step itself -- we don't want *both* kernel and GDB to issue a
single step each ...)
I haven't gotten to looking further into other hardware (IGEP,
Panda) -- that's next on the list.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
== Linaro GCC 4.5 ==
Re merged all the patches I've had to back out of Linaro GCC due to
various test failures. I've now found all the extra fixes/patches
necessary to make them go ... I think. Tested the build and test on ARM
and x86_64.
== Linaro GCC 4.6 ==
Continued getting the 4.5 patches forward ported to 4.6. I now have
about 4 patches waiting for review upatream, or ready to be posted.
Upstream review isn't happening though. This partly due to GCC being in
stage 4, but mostly due to Richard Earshaw being on sabatical, and the
other maintainers being inactive. I can see that I'm going to have to
abandon my hopes of only merging to Linaro GCC once it's been approved
upstream, and be content with merging to Linaro once it's posted upstream.
Started another test to rebase the Linaro 4.6 branch with the latest
from upstream. Once that's done, I think I'll start merging my changes
in, and call that our baseline. (There'll still be merges from upstream,
but the history will diverge.)
----
Upstream patched requiring review:
* Thumb2 constants:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* Kazu's VFP testcases:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html
* Jie's thumb2 testcase fix:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00670.html
== Week of Jan.31st--Feb.6th ==
* Vacation, Chinese New Year Holiday.
== Last week ==
* Monday (Feb.7th), last day of vacation.
* LP #711819, ICE in push_minipool_fix: this turned out to be a simple
case where a memory load alternative was not tagged with the minipool
range attributes. Patch sent upstream, awaiting approval.
* LP #709453, wrong code generated for NEON. Tracked this down and
mostly know how to fix this, but discussion with Ramana brought the
issue up that the entire idea of using NEON vmov.i32 for loading VFP
constants may not be good for A9, and unclear for A8. We probably should
just revert the patch from the Linaro tree for now.
* PR46002, IRA internal compiler error with -fira-algorithm=priority.
Been looking at this as a part of my background IRA studies. Have a
possible patch for this, plus found another assert fail ICE under ARM.
Will see if can post upstream this week.
== This week ==
* Continue to look at above unfinished issues, as well as other new ones.
== GDB ==
* Installed 2.6.37 Linaro kernel on IGEP and Versatile Express
in order to verify support for HW breakpoints/watchpoints
* Tested GDB HW watchpoints patch, fixed several bugs in the
patch and core GDB, and got it working reliably on vexpress
* Started discussion with Will Deacon (ARM) regarding possible
further enhancements to related kernel support
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
== String routines ==
* Copied an improvement I'd previously made to memchr (removing a
branch using a big IT block) to strlen
* Modified benchmark setup to build everything as a library to
fairly give everything a PLT overhead.
* Pushed optimised memchr and strlen and simple strchr into
cortex-strings bzr repo
* Patched eglibc to use memchr and strchr code - although currently
fighting to get appropriate .changes file
== ffi ==
* Kicked off TSC request for license permissions
== bugs ==
* Built and recreated the qt4-x11 bug, produced all the dumps and
boiled it down to a few lines of suspicious RTL for Richard.
** Away next week.
== GCC ==
* Finished testing fix for lp:709329 and got that merged.
* Wrote up a plan for GCC performance improvements based on what we
discussed at the sprint.
* Internal ARM tasks that kept me busy for most of last week and this week.
Plans:
* still stuck on some ARM internal tasks for next week.
== This week ==
* Got the STT_GNU_IFUNC work ready to submit. Split out some preparatory
patches, including fixes for some general ARM inefficiencies that I
noticed this week. Ran the EGLIBC testsuite (including ifunc tests)
and they passed.
* Discussed ideas for representing permuted vector loads with Ira.
I'm still um-ing and ah-ing about the various possible approaches,
but I think I understand the constraints a bit more now.
* Fixed Qt miscompilation (lp #705689).
* Fixed PC-relative load bug in the assembler (lp #716967).
== Next week ==
Holiday!
Richard
RAG:
Red:
Amber: DATE/QEMU conference still hasn't confirmed I have a place...
Green: qemu-linaro first release made!
Current Milestones:
| Planned | Estimate | Actual |
first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 |
Historical Milestones:
finish virtio-system | 2010-08-27 | postponed | |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 |
finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off |
* maintain-beagle-models:
+ first qemu-linaro release (2011.02-0) made on time
+ fixed OMAP3 MMC controller model bug that was causing the kernel
to hang when enabling a swapfile; pushed fix to qemu and meego trees
+ rebased qemu-linaro on new upstream
* merge-correctness-fixes
+ reviewed some softfloat patches from Christophe; testing of
the half-precision floating point conversion instructions
showed up a number of other bugs which I submitted patches for:
http://patchwork.ozlabs.org/patch/82594/ (n/6)
+ reviewed and tested Christophe's patches for VQMOVUN and
VSLI.64/VSRI.64; these have been committed upstream
+ fix compile failure if !CONFIG_USE_GUEST_BASE
http://patchwork.ozlabs.org/patch/82630/
+ remove stray #include halfway through source file
http://patchwork.ozlabs.org/patch/82661/
+ improved vmull.p8 implementation over the meego version, sent
upstream: http://patchwork.ozlabs.org/patch/82657/
+ upstreamed patch to fix VQDMLSL:
http://patchwork.ozlabs.org/patch/82752/
+ upstreamed patch fixing thumb-to-arm neon dp insn conversion:
http://patchwork.ozlabs.org/patch/82757/
+ upstreamed patches fixing Neon VZIP and VUZP
* other
+ did a quick estimate of required effort to do vexpress model
(answer: 2 weeks if we don't want audio/USB/compact flash)
+ usual crop of standing meetings
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
17/18 March: QEMU Users Forum, Grenoble
Holiday: 22 Apr - 2 May
9-13 May: UDS, Budapest
(maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver
Hi,
* moved from Ubuntu Maverick to Natty on the PandaBoard
* investigation on the LTTng User Space Tracer:
https://wiki.linaro.org/KenWerner/Sandbox/LTTng
* started to look into latrace:
https://wiki.linaro.org/KenWerner/Sandbox/latrace
The idea is neat but there are issues in case the users code does dlclose
on a shared object. I'll investigate further when time permits.
* spent some time on IBM internal process work
Regards
Ken
