On holiday last week and at connect week before that.
==Progress===
* Recovered from jet-lag and started to catch up on email.
* Patch review week.
* Cleared out a bit of my patch backlog.
* Helped Asa with some bug triaging.
* Read up a bit about ssat and usat and what we should be doing with
other tuning for them.
* Looked up some performance profiles with v8 benchmarks . Reviewed the Android
benchmark numbers.
* Booked tickets for connect 2012.q2
* Wrote up connect week discussions on libav regressions .
=== Plans ===
* Clear out more pending patches ( PGO next on the hit list and the
vmla investigation)
* Investigate partial-partial PRE results.
* Finish off the ABI tests.
Absences.
* 1 week holiday sometime before that - to be booked.
* Linaro Connect Q2.12 - May 28 - June 1
Hi,
OpenEmbedded:
* added initial support for the Linaro GCC 4.6 based toolchain to
the meta-linaro layer.
* allows to build the Linaro toolchain the OE way
* successfully built the core-image-sato
but when running inside QEMU the GUI isn't usable
(needs investigation)
glibc:
* built glibc+glibc-ports natively on ARM
* the upstream glibc testsuite isn't aware of the multiarch paths
and therefore it won't find some libs (libgcc_s, libstdc++)
* workaround using symlinks; wiki updated:
https://wiki.linaro.org/KenWerner/Sandbox/HowToBuildToolchainComponents#gli…
Regards,
Ken
+ linaro-toolchain
Hello Ulrich,
I want to revisit this old thread. Sorry for the sloppy follow-up. But,
this time around I have more data.
On Tue, Mar 15, 2011 at 9:00 PM, Ulrich Weigand
<Ulrich.Weigand(a)de.ibm.com> wrote:
> Aneesh V <aneesh(a)ti.com> wrote:
>
>> I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
>> until I added some patches recently. One of these patches introduced an
>> API (let's say foo()) that has a weakly linked alias(let's say
>> __foo()) and a strongly linked implementation(the real foo()) in an
>> assembly file.
>>
>> Although I give -mthumb and -mthumb-interwork for all the files,
>> apparently GCC generates ARM code for assembly files. In the final
>> image foobar() calls foo() using a BL. Since foobar() is in Thumb and
>> foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
>> to be Thumb because __foo() is Thumb.
>
> I'm unable to reproduce this. Do you have a complete test case?
>
> I've tried with the following small example:
>
> foo1.c:
>
> extern void foo (void) __attribute__ ((weak, alias ("__foo")));
>
> void __foo (void)
> {
> }
>
> int main (void)
> {
> foo ();
> }
>
> foo2.S:
> .text
> .align 2
> .global foo
> .type foo, %function
> foo:
> push {r7}
> add r7, sp, #0
> mov sp, r7
> pop {r7}
> bx lr
> .size foo, .-foo
>
> When building just "gcc foo1.c", I get:
>
> 0000835c <__foo>:
> 835c: b480 push {r7}
> 835e: af00 add r7, sp, #0
> 8360: 46bd mov sp, r7
> 8362: bc80 pop {r7}
> 8364: 4770 bx lr
> 8366: bf00 nop
>
> 00008368 <main>:
> 8368: b580 push {r7, lr}
> 836a: af00 add r7, sp, #0
> 836c: f7ff fff6 bl 835c <__foo>
> 8370: 4618 mov r0, r3
> 8372: bd80 pop {r7, pc}
>
> When building both files "gcc foo1.c foo2.S", I get instead:
>
> 00008368 <main>:
> 8368: b580 push {r7, lr}
> 836a: af00 add r7, sp, #0
> 836c: f000 e802 blx 8374 <foo>
> 8370: 4618 mov r0, r3
> 8372: bd80 pop {r7, pc}
>
> 00008374 <foo>:
> 8374: e92d0080 push {r7}
> 8378: e28d7000 add r7, sp, #0
> 837c: e1a0d007 mov sp, r7
> 8380: e8bd0080 pop {r7}
> 8384: e12fff1e bx lr
>
>
> So it seems to me the linker is handling this correctly ...
>
> (This is on Ubuntu Natty using system gcc and binutils.)
I could reproduce the problem on older tool-chain(Sourcery G++ Lite
2010q1-202) [1] with a modified version of your sample code:
a.c:
====
extern void foo (void) __attribute__ ((weak, alias ("__foo")));
void __foo (void)
{
}
extern void call_foo(void);
int main (void)
{
call_foo ();
}
b.S:
====
.text
.align 2
.global foo
foo:
push {r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo
c.S
.text
.align 2
.global call_foo
call_foo:
bl foo
bx lr
.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx lr
Now, I build them using the following commands, which is similar to
what U-Boot does:
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c c.S
arm-none-linux-gnueabi-ld -r a.o -o alib.o
arm-none-linux-gnueabi-ld -r b.o -o blib.o
arm-none-linux-gnueabi-ld -r c.o -o clib.o
arm-none-linux-gnueabi-ld --start-group clib.o alib.o blib.o
--end-group -o a.out
armobjdump -S --reloc a.out
You will get something like:
00008094 <call_foo>:
8094: fa000006 blx 80b4 <foo>
8098: e12fff1e bx lr
Please note that that the 'blx' is not correct. Now, do the following change:
diff --git a/b.S b/b.S
index e0f2de9..96dba1f 100644
--- a/b.S
+++ b/b.S
@@ -1,5 +1,6 @@
.text
.align 2
+.type foo, %function
.global foo
foo:
push {r7}
And build it again the same way and you will see:
00008094 <call_foo>:
8094: eb000006 bl 80b4 <foo>
8098: e12fff1e bx lr
I can't reproduce this on Linaro GCC 2012.01, so looks like the problem
is solved in recent tool-chains. However, sadly I could reproduce a
different but similar problem with Linaro GCC 2012.01. This time the
call is from C(Thumb) to assembly(ARM) and no weakly linked symbols are
involved.
a.c:
====
int main (void)
{
foo ();
}
b.S:
====
.text
.align 2
.global foo
foo:
push {r7}
add r7, sp, #0
mov sp, r7
pop {r7}
bx lr
.size foo, .-foo
.global __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0:
bx lr
arm-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
arm-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
arm-linux-gnueabi-ld -r a.o -o alib.o
arm-linux-gnueabi-ld -r b.o -o blib.o
arm-linux-gnueabi-ld --start-group alib.o blib.o --end-group -o a.out
arm-linux-gnueabi-objdump -S --reloc a.out
gives:
8076: af00 add r7, sp, #0
8078: f000 f802 bl 8080 <foo>
807c: 4618 mov r0, r3
It should have been "blx 8080 <foo>", isn't it? Again, %function
solves it.
I agree that not marking the assembly functions ' %function' is a problem
in the code, so it's not a critical bug. But I would've been happier if
the linker refused to link it rather than branching with the wrong
instruction. Isn't that a problem?
Problem No:2
*************
Linaro GCC 2012.01 is giving a new problem w.r.to Thumb build
that is not existing in Sourcery G++ Lite 2010q1-202. However, I
couldn't reproduce this problem with a small program like above. So,
let me give you reference to the original u-boot code that shows the
problem and steps to reproduce it.
tree: git://github.com/aneeshv/u-boot.git
branch: thumb
The above branch has mainline u-boot with 4 additional patches from me
for enabling Thumb build. You can build it like this:
make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm distclean
make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm omap4_sdp4430
This builds two images u-boot and u-boot-spl. SPL is a tiny u-boot that
runs from internal RAM and loads the u-boot to SDRAM. Now, please have
a look at the map file of u-boot-spl which is at: spl/u-boot-spl.map
I see the following in my map file:
/spl/u-boot-spl.map:
=================
.rodata.wkup_padconf_array_essential_4460
0x40309583 0x4 board/ti/sdp4430/libsdp4430.o
0x40309583 wkup_padconf_array_essential_4460
.rodata.wkup_padconf_array_essential
0x40309587 0xc board/ti/sdp4430/libsdp4430.o
0x40309587 wkup_padconf_array_essential
.rodata.core_padconf_array_essential
0x40309593 0x60 board/ti/sdp4430/libsdp4430.o
0x40309593 core_padconf_array_essential
Please note that the .rodata symbols have odd addresses. These arrays
actually need to be aligned at least to half-word boundary. In fact, in
the image I verified that they are put at even addresses. So, the
symbols have been kept as real address +1. I understand that this is
the convention for Thumb functions. I guess the tool-chain did it for
data too?? And I am getting unaligned access aborts on accessing them.
I notice that this doesn't happen with all .rodata. symbols in the
image. I couldn't see any difference between working and non-working
files nor any difference in the command used to build them!
Well, this doesn't happen if I don't use "-fdata-sections" in gcc
options. So, apply the following patch and you will see that those
symbols have even addresses now.
diff --git a/config.mk b/config.mk
index ddaa477..723286a 100644
--- a/config.mk
+++ b/config.mk
@@ -190,7 +190,7 @@ CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS) \
# Enable garbage collection of un-used sections for SPL
ifeq ($(CONFIG_SPL_BUILD),y)
-CPPFLAGS += -ffunction-sections -fdata-sections
+CPPFLAGS += -ffunction-sections
LDFLAGS_FINAL += --gc-sections
endif
/spl/u-boot-spl.map:
=================
.rodata 0x40309204 0x38c board/ti/sdp4430/libsdp4430.o
0x40309204 core_padconf_array_essential
0x40309264 wkup_padconf_array_essential
0x40309270 wkup_padconf_array_essential_4460
0x40309274 core_padconf_array_non_essential
0x40309540 wkup_padconf_array_non_essential
0x40309588 wkup_padconf_array_non_essential_4430
Will you be able to look into these?
Thanks,
Aneesh
[1] Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709
[2] Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 -
Linaro GCC 2012.01) 4.6.3 20120105 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22
Hi!
* Development benchmarks:
Focused on the implementation of development benchmarks in the cbuild
system. Discussed with Michael about how the comments should look.
I am now testing my solution in the launchpad staging area. You can see a
link to an example of a benchmark result comment below. (Should not be a
double comment of course, and the actual result files are only stored on my
machine for now.)
https://code.staging.launchpad.net/~ramana/gcc-linaro/partial_partial_pre_t…
The real benchmark names are not mentioned, since that might be sensitive.
* Bug reports
I got an action on Monday's meeting to investigate if
https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/926855
is the same as PR52294.
Investigated with help from Ramana and updated the ticket.
Regards
Åsa
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-??-?? || ||
(new blueprints & reestimate for this one pending Michael H's writeup/etc)
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 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 ||
== cp15-rework ==
* figuring out how various suggestions/conversations on this from
Connect ought to fit together
== other ==
* LP:928580 recent u-boot not booting on QEMU beagle: tracked
this down to a u-boot bug and passed to John Rigby
* investigated a linux-user segfault deadlock which turns out to
be because the guest program is using setrlimit to restrict
memory usage and one of qemu's internal memory allocations then
fails. Not clear how best to fix but was able to nack the suggested
patch...
* most of the patches for passing a device tree to the kernel from
qemu (via -dtb option) are now upstream; rebased the final patch
which should now go in soon I think
* LP885239 qemu-linaro broke booting of zaurus models: fixed a bug
where a trustzone support patch had broken some cp15 registers for
xscale cpus
* minor patch: fixed formatting of list of supported machines help text
* fix an embarrassing segfault bug in a patch of mine committed last week
* it turns out that we can detect at compile time whether glibc's
makecontext() is an always-fails stub : sent configure patch to do this
* travel mostly set up for connect Q2.12
* lots of meetings/training: toolchain call; standup; 1-2-1;
project management training; comms meeting
I've added a Cortex-A8 benchmark machine to my home office. The
machine is called 'nova1' and is part of the cbuild a8-ref queue.
Feel free to give it jobs:
http://ex.seabright.co.nz/helpers/scheduler/spawn
-- Michael
Hi,
GDB on Android exploration:
* Familiarizing myself with the Android SDK and NDK, and the Android
runtime environment.
* Set up a Linaro Android Versatile Express image running on Linaro
qemu. Updated the wiki page [1] with instructions on how to prepare
its initrd to make it palatable to qemu.
* Trying to figure out if there's a way to get the SDK and NDK to talk
to that image.
* Studied AOSP's patches to gdbserver, and also Mozilla's patches to
AOSP's GDB and gdbserver.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
[1] https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress
I've changed the bounce host used to gain access to the boards at my
home office. The ports and configuration are the same but you will
get a scary error due to the SSH host key changing.
Let me know if there are any problems,
-- Michael
* Linaro GCC
Discovered that part of my conditional execution problems were caused by
some over-zealous peephole optimizations adding CC register clobbers to
arithmetic operations in order to take advantage of the 16-bit encoding.
This is a problem because they can't be converted to conditional
execution so freely because overwriting the CC register prevents any
further conditional execution (and forces a 32-bit encoding
unnecessarily). I wrote a patch to help ifcvt unpick all this and DTRT,
and posted it upstream. It turns out that Benrd (I think) already
reimplemented the peephole optimization in the reorg pass, so all that
is really needed is to delete the now obsolete peepholes. Richard E has
approved the revised patch. Unfortunately I've now discovered that that
exposed a bug in the machine description, so that'll have to be fixed also.
Tried to update the gcc-linaro/4.7 branch, but found the build broken.
In fact, Matthias had already reported it to Bugzilla. I did a binary
search, identified the problem commit, posted the info to bugzilla, and
pushed a merge request for the last working commit for testing. This
tested ok, so I've merged it to the Linaro 4.7 trunk.
Brought the Linaro GCC patch tracker up to date to aid identification of
patches we will need to forward port to 4.7. The remaining 'red' patches
are either not committed upstream, or I wasn't sure.
Attempted to benchmark the 64-bit shift improvements, but the target
board (ursa1) has developed an I/O error.
* Other
Joe Seymour and I went to HP Bristol to attend one of their science
lectures. Professor Jim Al-Khalili gave a talk about the recent
"faster-than-light" neutrinos experiments, and explained why it can't
possibly be true.
http://www.jimal-khalili.com/blog/faster-than-the-speed-of-light.html
Summary:
* crosstool-ng patches for linaro 2012.02 binary toolchain release
Details:
1. Revise the gdb lsb build patches based on gdb-7.4.
2. Clean up old patches and only keep the latest version, since we
only keep the latest version in config for linaro.
3. Window installer patch.
* Scripts to use installjammer to create the win32 install package.
* Apply linaro logo to the install package.
* Sync up the install directory and Start-menu layout with
embedded toolchain.
* Test the package on win7.
Plans:
* Finalize 2012.02 binary toolchain release.
Best regards!
-Zhenqiang
Hi,
libunwind
* discussions about local unwinding on Android
* problem: dl_iterate_phdr isn't available
* idea: parse proc/<pid>/maps but to find the ELF file for a given IP
and get to the ARM specific unwind info from there
* assisted an Android game developer who is using clang to compile
the native parts of the app, the ndk to link it and wondered why
the debuggerd doesn't catch any crashes
OpenEmbedded
* mainly worked on the linaro meta layer
* got the external binary toolchain recipe working
* added the Linaro 3.1 Kernel to the layer
* updated documentation:
https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
Regards,
Ken
RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-02-20 || ||
(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 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 ||
== other ==
* post-Connect miscellany:
* got boot-wrapper into an official location in linaro git repo
* Exynos4 patchset finally made it through a review and is upstream
* vexpress-a15 model also now upstream
* put together arm-devs pullreq and got it committed
* LP:932856 : fix broken omap3 bootrom emulation of raw boot mode
* LP:931940 : fix failure to raise interrupts in PL031 realtime
clock model
* reviewed some qemu gdbstub patches that should fix a problem
with semihosting-via-gdb
* rebased qemu-linaro: another nasty one after upstream QOM
patches landing
* spent some time finishing up cleanup of the omap_i2c patches
in qemu-linaro (a job started and left unfinished a few months back)
== GCC ==
* Verified status of patches in Linaro 4.6 that might not yet
be in mainline / Linaro 4.7. Ported two of Ira's vectorizer
patches and created merge request.
* Successfully tested and benchmarked 4.7 version of Richard's
sched-pressure patch, with similar results as seen on 4.6.
Rebased branch due to conflicts with recent mainline merge;
will commit after retesting.
* Investigated LP #923397 (Broken alignment attribute). Now
fixed in FSF mainline and 4.6 branch, will get merged into
Linaro GCC 4.6 automatically for next release.
* Ongoing work on a patch to allow memory operands with vec_set
and vec_extract to avoid excessive vmov generation in the
PR 51819 test case.
* Started working on a patch to generate usat/ssat instructions
where appropriate.
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 Andrew,
thanks for bringing the 4.6 patch tracker up to date. I've had a look over
everything that's marked red to see what we need to do to bring Linaro 4.7
up to date:
106869 Add -fsched-pressure-algorithm=model and enable it by default on
ARM.
My recent commit of Richard's patch. I've tested a forward-port to the
Linaro 4.7 branch already, but had to rebase it due to merge conflicts
with the recent upstream merge, so I'll commit after retesting:
lp:~uweigand/gcc-linaro/sched-pressure-v2-4.7
106846 Handle non-constants in mixed size condition
106844 Support pattern detection for basic blocks.
Two of Ira's patches that have not yet landed upstream due to stage 3.
I've created a forward-port branch and will merge into Linaro 4.7:
lp:~uweigand/gcc-linaro/vect-patches-4.7
106789 Fix rs6000 vector expansion.
106768 Merge fix for lp721513.
These are actually already upstream (modulo minor cosmetic changes)
and present in Linaro 4.7.
All in all, once the two branches mentioned above are merged,
Linaro 4.7 will have everything that's today in Linaro 4.6.
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
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi!
* Finished gcc-4.7 benchmarking:
https://wiki.linaro.org/Internal/ToolChain/Benchmarks/gcc-4.7_benchmarking
Results uploaded to
lp:~linaro-toolchain-wg/linaro-toolchain-benchmarks/private-runs
* Development benchmarks:
Continued the work started at connect.
Got stuck for a while with a problem with the launchpad staging area. I
could no longer log in. Seems the staging area is reset at weekends. The
user credentials has to be given again, but you first have to remove them
manually from the GNOME keyring (or whatever place they are stored).
* Bug triaging:
Triaged these bugs: https://launchpad.net/bugs/926855,
https://launchpad.net/bugs/925991, https://launchpad.net/bugs/924726.
Regards
Åsa
Hi there. I've cancelled the Monday and stand up calls for this week.
Andrew, could you run the standup call on Thursday please? The
moderator details are at:
https://wiki.linaro.org/Internal/ToolChain
-- Michael
* Linaro GCC
Continued work on 64-bit shifts. My patch for shifts in core registers
was rejected because I used conditional-execution before it's safe,
apparently, so I've spent some time looking at the alternatives.
First, conditional move instructions were unsatisfactory - the final
instruction sequence was longer and therefore less efficient.
Second, if_then_else instructions (basically conditional execution
expressed a different way) was to limited - there were no patterns
compatible with "or with shifted input" available in ARM mode, and no
patterns available at all in Thumb mode. I solved that easily enough, of
course, but the result was still unsatisfactory. In Thumb mode the
result was roughly equivalent (conditional-execution is constrained by
IT blocks), but in ARM mode it uses patterns that output two opposing
instructions at once, without allowing for the possibility of scheduling
or other optimization.
Third, I've tried putting in ordinary branches and relying on the
if-conversion pass to transform that to conditional execution. I had not
done this initially, partially because I didn't know how, but mostly
because the original implementation I was trying to replace resulted in
branches in the output code, and I was trying to improve on that.
Anyway, I've now figured out how to do that, and initial testing
suggests that the if-conversion really is working this time. Even if it
doesn't always, the other improvements to the shift sequence should
still give a boost.
My other patch, to do 64-bits shifts in NEON (and fall back to the above
code when register allocation sees fit) has not yet been reviewed.
* Linaro Connect
This week was Linaro Connect week. I could not attend the event in San
Francisco in person this time, so I took part in some of the morning
sessions remotely.
Linaro have switched to using Google Hangouts for the remote
participation, and it went really rather well. In the old system there
was an audio stream to listen to (on a 20 second delay or so, usually),
and an IRC room projected onto a large screen for remote attendees to
respond. The new Hangout system is effectively a simple in-browser
video-conference system that allowed us to not only see the room, but
also respond verbally in real time. The only disadvantage is the
10-person limit, but I never saw any room get near that all week.
I successfully attended several sessions and one regular meeting
remotely by these means. And no jet lag or eating so much!
Hi,
Made the GDB 7.4-2012.02 release:
* Learned about cbuild and how to use its services.
* Prepared a GDB Linaro 7.4-2012.02~rc1 tarball and ran on cbuild.
* Compared test results on ARM and i686 with the ones from 7.3-2011.12.
Investigated new failures, determining that all come from new
testcases added since the last release. One seemed important but
when investigated it turned out to be a bug in the hand-written
debug info for the testcase, which is wrong on ARM. I opened
bug reports on Launchpad for the new failures which are worth being
investigated for future releases. There are no regressions
in 7.4-2012.02 compared to 7.3-2011.12.
* Executed the release process for Linaro GDB.
* Started exploring GDB on Android.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
OpenEmbedded-Core:
* tested the external-toolchain branch from C. Larson
* changes now upstream
* rebased my changes to the current oe-core trunk
* startet to setup a proper external layer at:
git://git.linaro.org/people/kwerner/meta-linaro.git
* got the minimal, sato and Qt image built again
(only two patches required on the oe-core tree)
Misc:
* remotely attended some Linaro Connect sessions
Regards,
Ken
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro GDB 7.4 2012.02.
Linaro GDB 7.4 2012.02 is the first release in the 7.4 series. Based off
the latest GDB 7.4, it includes a number of ARM-focused bug fixes and
enhancements.
Interesting changes include:
* Update to GDB 7.4 code base.
* The "info proc" and "generate-core-file" commands will now also
work on remote targets connected to GDBserver on Linux.
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.4-2012.02
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2012-02.
Linaro QEMU 2012.02 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
New in this month's release:
- A simplified A15 model (non-LPAE) which is sufficent to boot a
carefully-configured Linux kernel.
Known issues:
- Graphics do not work for OMAP3 based models (beagle, overo)
with 11.10 Linaro images.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.02
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
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>
