The Linaro Toolchain Working Group is pleased to announce the 2012.02
release of Linaro GCC 4.6 and Linaro GCC 4.5.
Linaro GCC 4.6 2012.02 is the twelfth release in the 4.6 series. Based
off the latest GCC 4.6.2+svn183786, it contains a few bug
fixes and backports Cortex-A7 and Cortex-A15 support from FSF trunk.
Interesting changes include:
* Updates to 4.6.2+svn183786.
* Add initial Cortex-A7 support.
* Backport Cortex-A15 tuning improvements from upstream.
* Backport improvements to 64 bit unsigned comparisons.
Fixes:
* LP: #917967 Backport the fix for PR51799.
* LP: #836588 armel FTBFS with gcc 4.5 org 4.6 O2 and fPIC.
* LP: #879725 ICE in int_mode_for_mode, at stor-layout.c:490.
Linaro GCC 4.5 2012.02 is the eighteenth release in the 4.5 series. Based
off the latest GCC 4.5.3+svn183785, it is a maintenance only release.
Interesting changes include:
* Updates to 4.5.3+svn183785.
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.6-2012.02https://launchpad.net/gcc-linaro/+milestone/4.5-2012.02
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.6/4.6-2012.02https://launchpad.net/gcc-linaro/4.5/4.5-2012.02
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? inquire at support at linaro.org
-- Ramana
Hi,
I'm doing some tricks with Linux kernel and I'm dependent on
bootloader atags passing.
On PandaBoard the u-boot is always passing DTF/Atags pointer in r2
register, and I'm kind of depending on it. I need to emulate this
behavior by -initrd qemu's argument. However it seems that
qemu-system-arm zeros the registers on the start, and places atags in
some hardcoded memory address no matter what.
Is this behaviour really OK? Isn't r2 register a proper way to pass
atags on ARM platform? If so, would you merge into mainline a patch
that implement this? I could write it, but I don't want end-users of
my work to have to patch and compile Qemu manually.
Please CC me, I'm not following actively these mailinglists.
Regards,
--
Dawid Ciężarkiewicz
Please take the time to comment on this mockup, would it be useful for you?
what other info you like to see to make your job easier, know what you have
on your plate, your WIs progress, what is next in priority ....
BR,
Mounir
---------- Forwarded message ----------
From: Guilherme Salgado <guilherme.salgado(a)linaro.org>
Date: Wed, Feb 1, 2012 at 9:54 AM
Subject: [RFC] Upcoming work view for individual engineers
To: linaro-dev(a)lists.linaro.org
Hi folks,
We're trying to make status.l.o more useful to engineers and the first
thing we're planning to do is a new page listing the upcoming work
assigned to a given person. I'm attaching a mockup of that view here and
we'd like to know what you think of it... Do you think that would be
useful to you? Is there any other information you'd like to see there,
or maybe a different way to present/group them?
Cheers,
--
Guilherme Salgado <https://launchpad.net/~salgado>
_______________________________________________
linaro-dev mailing list
linaro-dev(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Adjusted my 64-bit shifts patch to address Richard Earnshaw's concerns,
tested it, and posted the new one upstream.
Continued trying to figure out how ira-costs.c works, and in particular,
why it doesn't choose to do 64-bit stuff in NEON when I think it should.
Basically, the problem seems to be that when hard regs are *already*
assigned, prior to IRA (say because they are function parameters or
return values), then the allocator does not even consider the
possibility of moving that value to another register unless it
absolutely has to. It will merrily choose the worst possible option just
because it's the easiest decision.
Merged FSF GCC 4.5 into Linaro GCC 4.5. Likewise for 4.6. Pushed the
branches to Launchpad for testing. The 4.5 testing did not come back
totally clear, so this may delay the release a little. Hmmm.
Updated my FSF GCC 4.7 checkout and rebuilt it. This time the build
succeeded, so I've used it as the basis for a shiny new launchpad branch
"lp:gcc-linaro/4.7". I've created the release series to go with it.
Applied my new 64-bit shifts patch to the new GCC 4.7 Linaro branch and
submitted a merge request. This is mostly for the purposes of getting
the test results at this point.
Hi guys,
I compile a native gdb using linaro 2011.10 by “./configure
--host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi”, and
the gdb runs on arm target boards directly.
# gdb
GNU gdb (Linaro GDB) 7.3-2011.10
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb)
I can use it to debug native programs on target boards directly. For
example, attach process, set breakpoints, check registers and memory.
One issue is I can't see multi-threads, for example:
PID 646 is system_server by ps
"646 1000 159m S system_server"
Then I use gdb to attach it:
# gdb attach 646
(gdb) info threads
Id Target Id Frame
* 1 process 646 "system_server" __ioctl ()
at bionic/libc/arch-arm/syscalls/__ioctl.S:15
as you see, “info threads” only shows one thread but there are several
threads in system_server.
But if I compile a new program based on glibc and gnu libthread, I can
see multi-threads by the gdb.
So my questions are:
1. Should I compile the native gdb using android toolchain and android
bionic/libthread libraries?
2. Why can’t the current gdb capture multithreads for android
processes? This question is actually about the theory for gdb to know
multi-threads. In my opinion, both gnu and android use clone() to fork
threads and threads in one process have same tgid in kernel and all
threads return same getpid() value. Why not gdb just travel process
lists to find multi-threads?
Thanks
Barry
Hi,
* Learned the basics of bzr and examined the gdb-linaro repository.
* Went through Michael Hope's steps to import upstream's 7.4 branch into
bzr.
* Explored gdb-linaro bugs and blueprints in Launchpad to familiarize
myself with what has been done
and is planned or proposed to be done.
* Went through the gdb-linaro/7.3 branch to verify what needs to be
forward-ported to gdb-linaro/7.4.
Forward-ported 10 patches.
* Checked which Linaro Connect sessions would be of interest for me to
attend remotely, but
found out that only one will be available for remote participation.
* Worked very little on Wednesday since my laptop refused to turn on
again after I hibernated it.
I found out on the next day that plugging in an external monitor makes
it happy again (I didn't
have a monitor on Wed to try this out so I was stuck). Apparently the
LCD screen died.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
libunwind
* reviewed small patch from T. R. of Nokia who provided a bugfix
when searching for unwind table entry for an IP
OpenEmbedded
* build the OE-core images (minimal, sato and qt4e) with -O1 and -O0
* collected the ELF size and memory footprint and updated the charts
* encountered an issue when compiling Qt 4.8.0 using -O0. It causes
qdbusviewer fail to link
because an .LTHUNK symbol survives
* tested various compilers and optimization levels and
noticed that the .LTHUNK symbols do also survive with higher
optimization levels
* only the Linaro and ARM CSL toolchains seem to be affected
(FSF trunk, 46branch and 46release seem to work)
* provided a reduced testcase and opened lp #924726
* Linaro cc1 emits undefined label when using -fPIC -Os (lp #924889)
* already fixed upstream, Ramana is backporting to Linaro GCC
* look into the external-toolchain branch from C. Larson:
https://github.com/kergoth/oe-core/tree/external-toolchain
and tested it against CSL 2011.03 -> works fine
* started to document:
https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
Regards,
Ken
== GCC ==
* Benchmarking the 4.6 backport of subreg forward-propagation
confirmed that this is a net loss. On 4.7, microbenchmarks
suggest a different outcome (due to register allocator
enhancements), so I've created a 4.7 Bazaar branch including
the patch and submitted it for benchmarking.
* Implemented a patch to allow memory operands with vec_set and
vec_extract to avoid excessive vmov generation in the PR 51819
test case. Patch shows no regression on microbenchmarks; full
testing and benchmarking still outstanding.
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:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-02-20 || ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?||2012-02-01 ||
(for blueprint definitions: https://wiki.linaro.org/PeterMaydell/QemuKVM)
Historical Milestones:
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
== cp15-rework ==
* Since this isn't in the critical path any more we'll work on it
next quarter, and adjust its priority/due dates post Connect.
== qemu-kvm-getting-started ==
* finished writing up HowTo documents for reproducing the KVM
prototype and running it on a Fast Model:
https://wiki.linaro.org/PeterMaydell/KVM/HowTo
* did the last bits of testing enough to be able to say we've done
the initial prototype work for TCWG2011-A15-KVM, which means we
can close out the qemu-kvm-getting-started blueprint.
== other ==
* more upstream patch review, etc
* LP:926012: patches to support prctl(PR_SET_NAME, ...) in linux-user
mode, for the benefit of perl 5.14.
