Hi,
* I've spent some time for testing the patches that allow the GCC trunk
to bootstrap again on ARM and posted the results to gcc-testresults
* finally tested and posted the patch that optimizes the __sync_*
builtins (#681138) on gcc-patches
* investigated on the state of the crash utility on ARM (or rather its
prerequisites like kexec)
https://wiki.linaro.org/KenWerner/Sandbox/crash-utility
* I'm on holiday now :)
Regards
Ken
Hi,
On Wed, Dec 15, 2010 at 1:44 AM, Michael Hope <michael.hope(a)linaro.org> wrote:
> On Wed, Dec 15, 2010 at 1:05 PM, Steve Langasek
> <steve.langasek(a)linaro.org> wrote:
>> Hi Michael,
>>
>> On Wed, Dec 15, 2010 at 09:29:38AM +1300, Michael Hope wrote:
>>> Hi Steve. I'd like to hand the rest of this over to you if that's OK.
>>
>> Yep, we can take it from here. To be clear, is this an additional change
>> above and beyond what Matthias reports is currently in Ubuntu gcc
>> (http://lists.linaro.org/pipermail/linaro-toolchain/2010-November/000441.html),
>> and if so, in what version of Linaro GCC is it going to become effective?
>> Do we have documentation of what the relevant failure modes caused by this
>> change *look* like, so that we can at least be triaging them appropriately
>> until there's some documentation on how to fix the resulting bugs?
>
> There will be many failures in many packages. The problem is when you
> use conditional suffixes on instructions: previously the compiler
> would insert an implicit instruction before that; now we have to be
> explicit.
>
> The failures are easy to diagnose and fix. The build will fail with a
> message from the assembler along the lines of 'xxx instruction outside
> an IT block'. The fix is to find the inline assembly code, insert the
> appropriate IT instruction, and re-build. The assembler will validate
> the IT instruction against the following conditional instructions so
> the change is quite safe.
Did someone manage to find out which versions of binutils can silently
accept the IT instructions when assembling for ARM?
This affects what advice we should give on how to avoid breaking
upstream with our additions. The safest approach is #ifdefs, but it
will be better for maintenance if we can avoid this, since it will
render the code very messy.
Cheers
---Dave
Hi there. Some of the tr-* blueprints had work items in them and this
was interfering with the tools that the PM guys use. I've created new
engineering blueprints, pulled the work items across into them, and
added the new engineering blueprint as a dependency of the old TR.
Sorry for the blueprint spam. In most cases the new blueprint has the
same name and subject as the TR one, such as the TR:
https://blueprints.launchpad.net/linaro/+spec/tr-toolchain-4.5-in-distros
which is backed by the engineering blueprint:
https://blueprints.launchpad.net/gcc-linaro/+spec/4.5-in-distros
-- Michael
Hi Richard,
Recapping on this earlier conversation:
http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000030.htmlhttp://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000035.html
Is it worth another attempt to make a case to upstream for supporting
passing -mimplicit-it=thumb by default to gas?
According to my understanding of this issue, my argument would go as follows:
* gcc currently estimates the size of asm blocks, rather than
determining the size accurately.
* gcc cannot guarantee the right answer for asm block size when asm
blocks contain directives etc., however use of directives in asm
blocks is widespread
* gcc cannot guarantee the right answer for asm block size in
Thumb-2. gcc conservatively overestimates the size by assuming that
each statement of the asm block expands to 4 bytes.
* All of Ubuntu lucid and maverick has been built with
-mimplicit-it=thumb passwd by default, with no known build or runtime
failures arising from this (so size issues aside, we have confidence
that the resulting code generation is sound)
* -mimplicit-it=thumb -mthumb makes the asm block size estimation
unsafe: the asm block can exceed the estimated size even in the
absence of directives, which may lead to fixup range errors during
assembly.
* Following the principles already established for Thumb-2 in
general the estimation can be made safe (or, as safe as the
established Thumb-2 behaviour) by raising the assumed maximum
statement expansion size for asm blocks to 6 bytes, since
-mimplicit-it will add as most a single (16-bit) IT instruction to
each statement.
* The vast majority of all asm blocks are small (< 20 instructions,
say), so the overall overestimate in sizes will generally be modest
for any given compilation unit.
* -mimplicit-it is already _required_ by the Linux kernel and
possible other projects.
...so...
* With -mimplicit-it=thumb and a 6-byte asm block statement
expansion size estimate, we have toolchain behaviour which is as
reliable, and as correct, as it is in upstream at present.
* Layout of data in the compiler output will be more optimal in some
cases, and less optimal in other cases, compared with the the current
Thumb-2 behaviour, due to differing asm block size estimates. The
exact behaviour will depend on the distribution of conditional
instructions within asm blocks.
* Taken over a whole compilation unit, the total code size
overestimate (and therefore the impact on object layout) will normally
be modest, due to the small typical size of asm blocks.
* Behaviour for -marm will not be impacted at all.
If gcc currently estimated asm block code size accurately, then I
could understand upstream's objection; but as it stands it seems to me
we wouldn't be making anything worse in practice with the proposed
change; and there is no compatibility impact (other than positive
impact).
Of course, I may have some wrong assumptions here, or there may be
some background I'm not aware of...
Comments?
Cheers
---Dave
== Linaro GCC ==
* Finish testing for big-endian/quad-word patch on mainline, and
send upstream. Not yet reviewed by an ARM maintainer, but Joseph
suggested tweaking DejaGnu's target-supports to better reflect the new
capabilities of the vectorizer in big-endian mode. I've not looked into
that yet.
* Started looking at improving element/structure load/store intrinsics.
Made it so that the structs used for loads/stores are created in the
backend so that the types can be used directly by the builtins, but
discovered that the front-end/middle-end would not play along with that
plan as they are. Thought about ways to fix that.
* Some time spent on other CodeSourcery stuff.
The Linaro Toolchain Working Group is pleased to announce the release
of both Linaro GCC 4.4 and Linaro GCC 4.5.
Linaro GCC 4.5 is the fifth release in the 4.5 series. Based off the
latest GCC 4.5.1+svn167157, it includes many ARM-focused performance
improvements and bug fixes.
Linaro GCC 4.4 is the fifth release in the 4.4 series. Based off the
latest GCC 4.4.5, it is a maintenance release that fixes one problem
found through use.
Interesting changes include:
* A new performance focused extension elimination pass
* Speed and size improvements when loading constants
* Performance improvements on compound conditionals
* A range of correctness improvements
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.5-2010.12-0
and
https://launchpad.net/gcc-linaro/+milestone/4.4-2010.12-0
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
No changes have been committed to Linaro GDB 7.2 this month.
-- Michael
* Linaro GCC 4.4/4.5
Merged the latest CS patches and Linaro merge requests into Linaro GCC
(4.4 and 4.5). Ran regression tests. Yao's patch failed so I backed it
out, and made the release tarballs. Uploaded the releases to Michael
Hope for release.
lp:686381: luatex fails to build with gcc-4.5
Fired off a test build to reproduce the problem. Will come back to this
next week.
* GCC 4.6/4.7
Posted my various queued patches up to gcc-patches(a)gcc.gnu.org for review.
Looked at the state of the GCC 4.6 upstream build. There are currently
two problems:
1. libquadmath must be disabled in a cross-build for the bootstrap phases.
2. libstdc++ doesn't build. There is a patch for it on the mail list,
but it's not applied yet.
Once gcc 4.6 builds cleanly, I shall update the Launchpad 4.6 branch,
and declare that the baseline for our development. We'll then have
somewhere to commit and track patches awaiting GCC stage 1 development.
* Other
Caught up with email following my holiday.
Yet again, my IGEPv2 board suffered a corrupt file system. I've now
upgraded the kernel and configured it to use an NFS root. The board is
now somewhat less mobile, but should work more reliably.
Continued organizing the a brain-storming session for GCC optimization
improvements.
Organised flights and hotel for both the Linaro Sprint and CodeSourcery
annual meeting in January.
== Last Week ==
* Spent time tracking down a couple of regressions that appeared in the
new ltrace release-candidate tree. Submitted a bunch of patches to fix
the issues that were discovered during that process; most have been applied.
* Finished writing fairly generic code for handling ARM-specific unwind
tables, from lookup through decoding and dispatch. It uses a few
definitions specific to libunwind, but those probably could be
eliminated with more work.
== This Week ==
* Integrate new ARM-specific bits into libunwind framework.
* Rewrite part of a portability patch for ltrace and hope that those
changes reflect the very last effort that will be required for that
particular task.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi <yao.qi(a)linaro.org> wrote:
> Hi, Kernel WG,
> Can recent kernel handle NEON registers in corefiles?
>
> Seems we've had plan for this in "Ensure full NEON debug support" in
> https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Specs/BSPInvestig…
> Any progress on this piece of work? We want to handle NEON registers in
> corefiles from GDB, which required kernel dump them in corefile first.
Hmmm, actually that bullet may have ended up in the wrong place ...
since it's not a BSP-specific feature.
Anyway, looking at the kernel code, it looks like the VFP/NEON state
is not dumped into the core file. If it makes you feel better, the
state of the obsolete FPE extension registers is dumped, if used :/
My guess is that it shouldn't be hard to dump the VFP/NEON state, but
GDB and the kernel need to agree on the format.
Rather that trying to hack the existing register dump format in a
compatible way, I suggest it's simplest if the kernel creates an extra
section in the dump containing something like:
.long format_version /* reserved for future expansion - must be 0 */
.long FPSID
.long FPSCR
.long MVFR0 /* or 0 if not present in the hardware */
.long MVFR1 /* or 0 if not present in the hardware */
.long d0
.long d1
/* ... d2-d14 ... */
.long d15
If 32 D-registers in the hardware [
.long d16
.long d17
/* ... d18-d30 ... */
.long d31
]
I believe we don't need any extra flags to indicate whether the MVFRx
fields are valid, since 0 in these registers indicates the
VFPv2/legacy behaviour anyway. Note that some VFPv2 implementations
(such as ARM1176) do provide these registers, and where the hardware
has them, the kernel can fill them in when doing the coredump.
We _should_ be prepared to ignore these fields (or interpret them
differently) if a vendor-specific VFP subarchitecture is specified (by
(FPSID & 0x4000) == 0x4000)
The number of D-registers can be deduced from the FPSID and MVFRx
registers, so we don't need to record it explicitly.
When MVFRx are not present, there are 16 D-registers.
When MVFRx are present, and (MVFR0 & 0xF) >= 2, there are 32 (or more)
D-registers
This is just a sketch -- the ARM ARM is the authoritative reference on
the meanings of these bitfields.
Any views on this?
Cheers
---Dave
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
== GCC ==
* Tracked down root cause of GCC mainline bootstrap failure
on ARM (PR 46040 - "__DTOR_LIST__ undeclared").
== Miscellaneous ==
* Set up IGEP v2 board (w/ local disk, network, ...) as
native GCC / GDB build environment.
* Gave talk on Linaro at the "2010 Linux Community Event" at
Siemens Munich (w/ Arnd Bergmann).
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
