== GDB ==
* Prepared Linaro GDB 7.2-2011-02.0 release
* Committed two patches to implement LP #661253 (Improve
backtrace by using ARM exception tables) to mainline and
Linaro GDB 7.2
* Provided two follow-on fixes to the patch for LP #616000
(Handle -fstack-protector prologue code); both applied to
mainline and Linaro GDB 7.2
* Backported mainline fix for LP #685494
(gdb.xml/tdesc-regs.exp failure) to Linaro GDB 7.2
* Identified root cause of LP #711375 (gdb internal error
in inline_frame_this_id trying to debug a qemu target);
committed fix to mainline and Linaro GDB 7.2
* Worked on re-implementation of fix for LP #615978 (Failure
to software single-step into signal handler)
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
RAG:
Red:
Amber: DATE/QEMU conference still hasn't confirmed I have a place...
Green: qemu-linaro RC2 prerelease uploaded
Current Milestones:
| Planned | Estimate | Actual |
first qemu-linaro release | 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 | 2010-01-25 | 2010-01-25 | handed off |
* maintain-beagle-models:
+ RC1 packaging flushed out some bugs:
++ we include some binary blobs which we're better not distributing:
https://bugs.launchpad.net/qemu-linaro/+bug/709965
++ a couple of array overruns don't compile with our picky armel gcc:
https://bugs.launchpad.net/qemu-linaro/+bug/709711https://bugs.launchpad.net/qemu-linaro/+bug/711272
(both fixes sent and applied upstream)
++ we ought to include a fix for the "swp" in qemu-lock.h:
http://patchwork.ozlabs.org/patch/81205/
(patch sent upstream, no comment on it yet)
+ ...so I have rolled an RC2 tarball with these fixed
+ investigated why USB keyboard model doesn't work: it turns out
that the OMAP host USB model is basically just a stub
+ some warnings from qemu about bad width accesses are a symptom of
a nasty disagreement between gcc and the kernel about getting atomic
32 bit accesses:
http://www.spinics.net/lists/arm-kernel/msg113002.html
+ warnings from qemu about access to a nonexistent i2c register
appear to be a kernel bug in the i2c driver for OMAP36xx:
https://bugs.edge.launchpad.net/linux-linaro/+bug/645324
+ investigated a hang running images built with linaro-media-create's
--swap_file option. Still digging but I suspect the Linux driver
doesn't cope with an MMC card which can erase in zero time...
* merge-correctness-fixes
+ the usual upstream mailing list monitoring and code review
+ sent patch for PLI and hint space decoding fixes:
http://patchwork.ozlabs.org/patch/81711/
* misc
+ some non-Linaro time this week; may be more next week
+ some advance planning of what we might want to do with QEMU
in the future
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,
* I continued to setup the pandaboad but ran into #708883
- tested vaious various hwpacks and headless images
- used different power supplies and several SD cards
- built various test kernels from the linux-linaro-natty.git
* looked into the crash utility
* https://wiki.linaro.org/KenWerner/Sandbox/crash-utility#future%20areas
Regards
Ken
Trying to build qemu on a beagle board:
CC sparc64-linux-user/translate.o
cc1: out of memory allocating 26975704 bytes after a total of 70742016 bytes
# ls -lh target-sparc/translate.c
-rw-r--r-- 1 root root 191K Jan 31 12:05 target-sparc/translate.c
ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
(and probably more overall since the board has 500MB RAM total and
it hit the out-of-memory condition).
This seems a bit excessive to me, but do we consider it enough of
a bug to be worth looking into?
(I believe this source file has caused compile failures on the buildds
too, which have rather more RAM/swap than my beagle.)
-- PMM
Hello,
Profiling Denbech:
* The profiling information on x86 indicate that some benchmarks might need
to run longer as helper functions such as t_run_test are reported to be
hot.
So I've increased the time each benchmark is executed and will continue to
experiment with that for the problematic benchmarks until I start to see
more reasonable results.
* Opened PR711819 after having an ICE running DENbench with trunk (natively
built on ARM machine).
- I've started to look at an old patch for SMS that was written in 2005 by
colleague; Mostafa Hagog; to place the register moves in free slots.
Currently, they are placed greedily before each def thats needs them.
Thanks,
Revital
Hi,
I continued to work on vect_interleave and vect_extract implementation on NEON:
* debugged the compiler to find out what's the problem with
neon_vzip/vuzp<mode>_internal
* fixed it following Uli's advice
* checked how neon_vzip/vuzp<mode>_internal work for intrinsics by
writing tests
* fixed the patch according to Uli's comments
* now fully testing the patch
Thanks,
Ira
Hi,
I am trying to implement interleave_high/low and extract_even/odd
using vzip and vuzp instructions. I am attaching a patch that attempts
to do that. It uses already existing neon_vzip<mode>_internal. The
problem with it is that it doesn't express the fact that the two
outputs of vzip depend on both inputs, which causes wrong code
generation in CSE:
for
(a,b)<- vzip (c,d)
and
(e,f) <- vzip (g,d)
CSE decides that b==f, since on RTL level b and f depend only on d.
Here is neon_vzip<mode>_internal:
(define_insn "neon_vzip<mode>_internal"
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
UNSPEC_VZIP1))
(set (match_operand:VDQW 2 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
UNSPEC_VZIP2))]
"TARGET_NEON"
"vzip.<V_sz_elem>\t%<V_reg>0, %<V_reg>2"
[(set (attr "neon_type")
(if_then_else (ne (symbol_ref "<Is_d_reg>") (const_int 0))
(const_string "neon_bp_simple")
(const_string "neon_bp_3cycle")))]
)
Is there a way to properly mark the dependence?
Thanks,
Ira
Hi; this is a note to say that we have now produced a prerelease
tarball of qemu-linaro. (The first formal qemu-linaro release will
happen in sync with other toolchain group releases on 8th Feb.)
This prerelease is primarily to pipeclean the release process and
to allow work to start on producing Ubuntu and Linaro packages;
however it does include a number of useful bugfixes which are
required if you want to be able to boot a recent Linaro snapshot
on the beagle model. So the enthusiastic might like to build it
from source and give it a spin.
Like the Linaro kernel trees, the qemu-linaro tree aims to only
include patches we are confident will go upstream; at the moment
this means the OMAP3 support and ARM correctness fixes from
the qemu-meego tree, based on the qemu upstream trunk.
You can download the source tarball from:
https://launchpad.net/qemu-linaro/+milestone/2011.02
-- Peter Maydell
Hi,
What do people understand to be the expected semantics of IT blocks
in the cases below, of which there has been some confusion
in relation to a recent Qt issue.
The code in question had a sequence something like:
comparison
IT... EQ
blahEQ
TEQ
BEQ
The important bits here are that we have an IT EQ block and two special cases:
1) There is a TEQ in the IT block - are all comparisons in the block
allowed and do their effects immediately take
effect? As far as I can tell this is allowed and any flag changes are
used straight away;
2) There is a BEQ at the end of the IT block, as far as I can tell,
as long as the destination of the BEQ is close it shouldn't
make any difference if the BEQ is included in the IT block or not.
Does that match everyone elses understanding?
Dave
Hi all,
With gas, does anyone know of a way to create a section whose name is
based on that of the current section?
The specific requirement is to be able to define a generic macro like
the example "fixup" below, whose purpose is to record ancilliary data
related to some other section. To illustrate:
.macro fixup
100\@ :
.pushsection fixup<current section name>, "a"
.long 100\@b
.popsection
.endm
.text
...
fixup
.long sym1
...
.section .other, "ax"
...
fixup
.long sym2
The linux kernel uses a technique just like this for patching SMP
kernels at bootup to work on uniprocessor platforms (when
CONFIG_SMP_ON_UP is enabled), resulting in code looking something like
this:
void exit __attribute__ (( __section__ (".text.exit") ))
{
...
asm(
...
FIXUP("something")
...
);
}
Note that the inline asm may actually come out of a generic header
file rather than being explitly written for this invocation. So it
may have to be truly generic.
Is far as I have been able to determine, it's not possible to generate
sections named based on the current section. In practice, the kernel
puts all the fixups into a single section.
The downside of this is that when sections are selectively discarded
at link time (which in general may happen -- for example, Linux
discards the "module exit" code for drivers which are built into the
kernel and therefore never exit) there is no way to selectively
discard the related fixup entries. Currently the only solution is to
include all the module exit code in the image and discard it at
run-time when the kernel boots. This is obviously wasteful.
Attempting to discard that code at like time results in a link error,
since fixups refer to the removed sections.
Of course, the "fixup" macro could be given an extra parameter to name
the containing section, but the macro can then no longer be called in
a generic way: all the calls to that macro must be manually (and
buggily) maintained to ensure that the referenced section name is
correct, some object post-processing must be done before linking,
and/or a tool must be created to implement the missing assembler
functionality. Unfortunately, such solutions are likely to be too
fragile or complex to make it upstream.
It's interesting to note that the same problem will apply for any
section containing ancilliary data for another section. In
particular, it looks like either the ABI or the assembler has had to
grow a special-case workaround for this in order to support exception
unwind information sections generated by .fnstart ... .fnend in a sane
way: the unwind information sections get called .ARM.ex{idx,tab} for
.text, and .ARM.ex{idx,tab}<section> for any other section. As a
consequence, link-time discarding can handle this information
properly, but IMHO this is a bit of a cheat and admits the general
need to create sections with names based transparently on those of
other sections, without satisfying that need. .popsection is also an
example of such a cheat: most other aspects of assmbler state still
cannot be saved and restored.
In general, it would be useful if gas supported some general
reflective abilities: i.e., the ability to query the current assembler
state (section, subsection, active instruction set, active macro mode,
etc.) and/or the ability to wrap or hook existing pseudo-ops. For
example, the above problem would almost certainly solvable using
assembler macros (albeit painfully) if wrapper macros could be defined
for the section manipulation directives (section, .text, .data, .bss,
.pushsection, .popsection, .previous). However, supporting some magic
macro parameters reflecting the assembler state would be a lot
simpler.
As an example of the kind of behaviour I think would be useful, the
macro argument qualifier could be extended to allow macros to query
the assembler state in a backwards-compatible way; something like:
.macro fixup base_section:gas_current_section_name,
old_altmacro:gas_macro_mode
.altmacro
LOCAL fixup_location
fixup_location:
.pushsection \base_section\().fixup
.long 100\@b
.popsection
\old_altmacro
.endm
Existing assembler code will continue to work just fine with this approach.
Note how this also enables a local label to be generated hygenically,
by making it possible to save and restore the macro mode. Otherwise,
.altmacro (and hence LOCAL) is hard to use safely, since the initial
macro mode is unknown and can't be restored.
Any thoughts / comments?
Cheers.
---Dave
== Last week ==
* PR47246, VFP index range on Thumb-2. Submitted and committed patch
upstream.
* Pinged two upstream submissions on gcc-patches, one for PR44557 and
the other a patch for LP:689887; still awaiting approval.
== This week ==
* Chinese New Year Holiday, I'll be off until Feb.8th.
Created a Google docs spreadsheet to help visualise the benchmark
results. The graphs are not very informative yet - too many lines and
too much noise. I'm going to have to revisit them.
Continued trying to build Android. The toolchains build fine, but
Android itself complains about -Werror, and there are a few other real
errors too. Considering I was told it built fine with GCC 4.6 and all I
needed to do was tweak 4.5 to match, I'm not terribly impressed. I'm
sinking too much time into fixing up Android, and I haven't even got to
looking at the compiler trouble. Alexander Sack has said he will try to
get me to a more appropriate starting place (I think), so I'll see what
happens there.
Discussed my maddhidi4 patch with Richard E (wearing his GCC ARM
maintainer hat). He's not convinced that my change won't make something
else produce worse code. I can't prove that it won't either, so I'm
going to have to revisit it.
Wrote up the GCC 4.6 branch policy and upgrade plan.
Just a reminder that the dial-in numbers for today's and all future
calls has changed. See:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings
for the new list. I'll hang out on IRC just before the meeting to
help the lost...
-- Michael
RAG:
Red:
Amber:
Green: qemu-linaro RC0 prerelease uploaded
Current Milestones:
| Planned | Estimate | Actual |
first qemu-linaro release | 2011-01-11 | 2011-01-11 | |
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 | 2010-01-25 | 2010-01-25 | handed off |
* maintain-beagle-models:
+ went through diffs between qemu-linaro and qemu-meego to
confirm we hadn't dropped any patches by mistake
+ tested qemu-linaro tree on ubuntu netbook image: boots OK
+ investigated and fixed qemu bugs caused by new x-loader
https://bugs.launchpad.net/qemu-linaro/+bug/704484
and new u-boot:
https://bugs.launchpad.net/qemu-linaro/+bug/703094
+ made merge requests to meego for a CRIS compile failure
and the x-loader bugfix
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/4http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/5
+ Went through the process of doing a qemu-linaro release
with a "RC0" prerelease as a pipecleaning exercise and
to provide a tarball to slangasek for doing packaging. Download:
https://launchpad.net/qemu-linaro/+milestone/2011.02
Release process writeup:
https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess
* merge-correctness-fixes
+ the usual upstream mailing list monitoring and code review
+ tested and sent meego VQ(R)DMULH.s16 fix upstream:
http://patchwork.ozlabs.org/patch/80725/
+ working on a patch to fix decoding of the preload and hint space
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
SPEC
Tried to track down what was going on with lbm; it doesn't seem to
be repeatable on canis1; I'd previously seen it fail at O1 and work at
O0 and tried to chop down the flags between the two; but after adding
all the flags back in on top of -O0 it still worked and then I tried
-O1 again and it worked. Going to try on another machine, but it
might be uninitialised data somewhere.
Panda
Our panda arrived; it's now happily nestling near our Beagles and
running the 0126 headless snapshot (with 0127 hwpack). It seems fine
except
for rather slow USB and SD IO. Tip: Panda's do absolutely nothing (no
LEDs, no serial console activity) unless you put an SD card
in with the firmware on.
Libffi
Wrote the changes for armhf. Tested on arm, armhf, i386, ppc and
s390x - all happy. (Not too unsuspectingly variadic calls just work
on everything other than armhf without the api change)
Mailed Python CType list asking how much of a pain the API change
will be and any hints on what might be affected.
Awaiting sign off for submission of code.
Optimised library routines
Looked at benchmarking 'git'; I'd seen previous discussions where it
had been pointed out that it spends a lot of time in library routines;
and indeed it does spend useful
amounts in memchr, memcpy and friends on a simple git diff v2.6.36
v.2.6.37 > /dev/null of the current kernel tree produces a useful
~25second run.
One interesting observation is that the variation in the times
reported by 'time' - i.e. user, system and real, the variation in
user+system is much less than either user or
system individually and is quite stable (within ~0.7% over 10 runs).
I've just tried preloading my memchr routine in and it does get a
consistent 1-1.2% improvement which does look above the nice.
Also asked on libc-help list for suggestions as to other benchmarks
people actually trust to reflect useful performance increases in core
routines as opposed to totally
artificial ones.
Dave
== GCC ==
* Determined root cause of #Bug 598462 (corrupted profile info
with -O[23] -fprofile-use), identified work-around (using
-fprofile-correction), and verified on GCC 4.5 and 4.6
== GDB ==
* Worked on re-implementation of fix for #615978 (Failure to
software single-step into signal handler)
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
== GCC ==
* Internal ARM tasks that kept me busy for some time this week.
* Reworked the divmodsi4 patch based on comments. Still some test
failures that need to be investigated.
* Started working on the performance improvement plan for GCC 4.5.
* Number of patch reviews upstream.
* Looking at A9 memset issue. .
* Got an internal bug report about the 4.4 tools from someone using it
which had to do with a missing backport. This is now lp:709329.
Backported and testing.
* Backported a missing upstream patch into GCC 4.5 for bswap patterns.
* Wrote up on how to cross-test with qemu and updated that on the
Linaro wiki. Comments are welcome.
Plans:
* Find out the default number of iterations needed for steady state
with EEMBC.
* Finish testing fix for lp:709329 and get that committed.
* Finish off divmodsi4 patch and get it's testing completed and
finished.
* Submit backport for bswapsi at Os fix (PR44392) for gcc-linaro
* Finish the plan for GCC performance improvements based on what we
discussed at the
sprint.
* Away 2-1/2 days next week for an internal engineering conference.
This week
=========
- On other IBM duties until today. Now finished!
- Looked at the neon failures that Peter reported. I'm testing patches
for the ICE and the "must be a constant" error now.
- In the background, I've been trying to pin down the chromium build
failure. I can only reproduce it when running under dpkg-buildpackage:
if I run the link line manually, it works. This is reminiscent of a
problem that Dave saw elsewhere: the linker segfaulted only when run
through the normal build system.
Next week
=========
- Bernd Schmidt has committed our combined patch for #695302.
Will backport to our sources.
- Submit the neon fixes above.
- More on STT_GNU_IFUNC. There are some more tests I want to write.
Richard
Some news from the qemu mailing list that I think might be
of interest to gcc folks here:
Christophe Lyon from ST has kindly released a large
set of test cases of Neon intrinsics:
http://gitorious.org/arm-neon-tests/arm-neon-tests
(the tests themselves are more aimed at testing qemu,
so they just produce output to be compared against a
reference generated from running on hardware).
However they don't currently compile with gcc (but
are ok with armcc). From the README:
# The tests currently fail to build with GCC/ARM:
# - no support for Neon_Overflow/fpsrc register
# - ICE when compiling ref_vldX.c, ref_vldX_lane.c, ref_vstX_lane.c
# - fails to compile vst1_lane.c
# - missing include files: dspfns.h, armdsp.h
Maybe it's worth somebody having a look at this,
at least enough to find out whether the ICEs are
things we already know about or have perhaps
already fixed in linaro gcc?
thanks
-- PMM
Hi,
I am working on implementation of interleave_high/low and
extract_even/odd for NEON. The pairs of high/low (even/odd) are
"magically" united into single vzip (vuzp) instruction in the back
end, so there is no need in special support from the tree level. There
are still some test failures that I need to solve.
Ira
Hi,
I've written up a wiki page finally on the cross-testing with qemu
here. It's taken me slightly longer than expected as I was playing
around with moin-moin syntax. These are based on qemu-0.13.0 which is
what I tried when I wrote this up for some testing of a patch that I
was playing with.
https://wiki.linaro.org/WorkingGroups/ToolChain/CrossTestingQemu
Comments are welcome .
Ramana
