Summary:
* Bug fixes.
* Tune ivopt for code size.
Details:
1. Reproduce lp:1007353 "kernel build fails with 12.04 and 12.05
toolchain released" and workout a patch to fix it; reopen the related
binutils/gas bug http://sourceware.org/bugzilla/show_bug.cgi?id=12698
and propose the patch to it; push the patch to linaro crosstool-ng to
make sure lp:1007353 is fixed for next binary toolchain release.
2. Setup the SPEC build env and reproduce lp: 886124 "using LDR from
literal pool rather than MOVW/MOVT". After cprop1 replaces lo_sum
(high: symbol_ref bloc) (symbol_ref (block)) with a (symbol_ref
(block)), no later optimization can split it. The solution in linaro
4.5 is to add a split (porting from codesourcery) in arm.md. Then
split1 can split the (symbol_ref (block)). The split is:
(define_split
[(set (match_operand:SI 0 "arm_general_register_operand" "")
(match_operand:SI 1 "general_operand" ""))]
"TARGET_32BIT
&& TARGET_USE_MOVT && GET_CODE (operands[1]) == SYMBOL_REF
&& !flag_pic && !target_word_relocations
&& !arm_tls_referenced_p (operands[1])"
[(clobber (const_int 0))]
{
arm_emit_movpair (operands[0], operands[1]);
DONE;
})
3. Tune ivopt for code size. Try to set avg_loop_niter to 1 since loop
iterator number does not impact code size. But test shows there is no
improvement. Need more tuning.
Plans:
* Analyze the failed cases in arm-linux-gnueabihf regression test.
* Tune code size for M0.
Best regards!
-Zhenqiang
Hello Sir/Madam,
I am using MK60FN1M0VLQ12 (COTREX-M4) processor for my development.
I am using float and double data types in my code. When I perform any
mathematical operation on these variables, the processor goes to Hard Fault
Exception.
Earlier I have used GCC 4.5.2 compiler for my compilation
So now I am using Linaro's GNU-GCC Toolchain 4.6.2 for compiling my code
with following command.
arm-none-eabi-gcc -Wall -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mcpu=cortex-m4
-mthumb -Qn -Os -mlong-calls -c main.c -o main.o
But I am getting following error while linking my code
ld: section .text.startup loaded at [00032258,000331cb] overlaps section
.InitializedVariables loaded at [00032258,00032787]
The link file is attached with this mail.
Can you please suggest me some solution for this problem.
Can you also suggest some compiler commands to support float and double data
type using software.
Awaiting for your reply,
Thanks & Regards,
Akash
== GCC ==
* Worked on reimplementing reassociation pass based on
review comments I had received.
* Identified root cause and worked on fix for vectorizer
bug causing unaligned memory accesses (reported by Mans).
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,
OpenEmbedded-Core/meta-linaro:
* fixed the binary toolchain support on master (still 2012.03)
* fixed armhf support for Linaro GCC 4.6 on master
* backport of Linaro GCC 4.7 r114985
* tested the images using QEMU - no failures
* now the master branch supports building images for ARM, MIPS, PPC,
X86 and X86_64 using the latest (2012.05) releases of Linaro GCC
4.6 or 4.7
* add tags on meta-linaro to easily find the revision for a particular
Linaro GCC
* changed cbuild to pull in the master branches of OE-Core and
meta-linaro
* merged the branch that allows to build OpenEmbedded-Core using cbuild
http://bazaar.launchpad.net/~kwerner/cbuild/oecore/changes/
* updated docs on the wiki
Misc:
* public holiday on Thu, vacation on Fri
* I'll be back on Monday : )
Regards,
Ken
Hi,
GDB for Android:
* Submitted and committed trivial patch to gdbserver which made it
compile again on Android. A patch had been added which made gdbserver
use a MIPS-related constant which Android doesn't provide.
* Compared testsuite results of GDB on Android vs regular Linux.
Unfortunately there's a lot of noise because the GCC 4.4 used by
the Android SDK generates bad debuginfo which confuses GDB and breaks
a lot of tests. Overall, it seems GDB on Android is in a generally
good
shape. Still need to run the testsuite again with an Android based on
a newer compiler to have a better comparison.
* Mozilla has a GDB patch to call gdbarch_addr_bits_remove before
comparing PCs in breakpoint handling which seems like a sensible thing
to do. Still, running the testsuite with and without this patch didn't
make a difference on Android or regular Linux.
* Remotely attended the GDB for Android session at Connect. Prepared
the following page to go with it:
https://wiki.linaro.org/ThiagoBauermann/Sandbox/AndroidGDBConnectSession
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
GDB for Android:
* Created patch to expand the ~ in "set solib-search-path". Despite
doing the right thing in other commands, GDB doesn't understand ~ in
solib-search-path, which made me lose some time in a debugging session
trying to figure out what was going on. Committed upstream.
* Looked into AOSP patch which hardcodes use of fork tracing instead of
thread events. Found out that gdbserver actually already prefers fork
tracing on both Linux and Android (tested on ICS and Linaro 12.04).
This must have been a problem in some earlier version, and the patch
is
unnecessary now.
* Set up a QEMU instance with Linaro Android 12.04. Got dropbear ssh
on it and ran the GDB testsuite remotely on the VM.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
OpenEmbedded-Core/meta-linaro:
* added a default xorg.conf for the qemuarmv7a MACHINE
* necessary because OE-Core master switched from Xfbdev to Xorg
* noticed that hard float with Linaro GCC 4.6 works on denzil but is
broken on master
due to differences on the requested/provided interpreter
* it used to (accidentally?) work when /lib/ld-linux.so.3 was used
even for armhf
* need to check out what loader name OE-Core really wants to use
* worked on getting OE-Core to build with Linaro GCC 4.7
* verified that the recipes for Linaro GCC 4.7 are working for ARM,
MIPS, PPC, X86, X86_64
* all images are working!
* updated the wiki pages
Regards,
Ken
Linaro Connect edition...
RAG:
GREEN: productive Connect, hammered out a KVM TODO list
* As usual, most sessions don't really intersect with KVM/QEMU work,
so the bulk of the benefit of the week was in informal discussions
and hacking sessions. Useful outcomes there:
* Dragged Rusty through some of the more obscure corners of the
ARM architecture, in the course of doing a review of all the
A15 cp15 registers and how KVM should handle them
* Thrashed out a todo list for getting to "initial upstreamable
patchset" for KVM:
https://docs.google.com/document/d/1TSpDKQZ-6u-HH_2BNY_85jDStI2YDhENf5-z8Nb…
* Nailed down a few decisions we'd left hanging for a bit
* A few sessions that seem worth mentioning:
* Enterprise bootloaders
Jon M definitely pushing the idea that servers will want ACPI,
UEFI, etc all to look as consistent and like x86 as possible. This
includes a desire for UEFI in the virtual environment provided by
QEMU/KVM. We've been aware we might want to do that, but there is
definitely some work to do to get UEFI running (probably a combo of
QEMU bugfixes/feature work and patching UEFI). Total work required
hard to estimate because you just have to keep fixing bugs until it
works... (The push for UEFI was repeated in a couple of other
sessions too.)
* v8 discussion
The question of whether there will be a v8 QEMU was raised (again).
There do seem to be enough people interested that we should be able
to collaborate on a user-mode emulator, which I think is a good
outcome. This will obviously depend on release of enough public
info on the architecture.
* KVM performance
Bit of a null session, as it turns out that we aren't really ready
to think about performance. We believe there aren't any obvious
areas requiring optimisation in the current KVM patchset. Virtio is
the only thing to be added later, and this is really just missing
QEMU side rather than needing specific kernel support. We did take
the opportunity to go through our TODO list for KVM functionality;
nobody raised anything we'd missed, so that's good.
-- PMM
