Hi there. Starting next week we'll switch to the Zip conference line. See:
https://wiki.linaro.org/Resources/ZipConferenceLine
under 1-719-457-1414 for a list of numbers. A selected few are:
UK 0 808 101 1146
Germany 0 800 181 9019
Sweden 02 079 7556
Brazil, Sao Paulo Local +55 11 5582 6534
Australia 1 800 105 680
China +400 148 5400
NZ 0800 451 015
The code is 763 804 0680. I've updated the meeting calendar and will
update the wiki page once Monday comes around. The moderator code is
on the toolchain internal page.
Amber, could you update the public event please?
Ramana, could you update the performance call for two weeks time?
Maybe move it to linaro-events so I can edit it.
-- Michael
Hi Michael,
So, I gave my best shot at:
https://bugs.launchpad.net/gcc-linaro/+bug/914703
Kind of similar to the one in your walk-through, but I couldn't actually
reproduce on the version reported.
Could you please check if this looks OK?
Regards
Åsa
Hi Åsa. I've triaged a bug and written down my notes on the way. See:
https://wiki.linaro.org/MichaelHope/Sandbox/TriageRunThrough
This one turned out to be easy but at least you have the basics.
Could you triage the bug for real and see what I've missed?
I'm unsatisfied with the result on that bug. The fault is in the
Ubuntu Natty compiler which we've long since fixed in Linaro GCC. It
would be nice if we could point the bug reporter to an updated GCC.
Ask Marcin and Matthias what they think.
-- Michael
Summary:
* Enhance crosstool-ng build process.
Details:
1. crosstool-ng patches:
* Reproduce the build process by following the README and enhance
the document.
* Update .config to strip all toolchain executables
* Replace harded-coded VERSION by reading config file.
* Remove host libiberty.a
* Patch on how to strip debug sections is in discussion.
2. Update the crosstool-ng based embedded toolchain build scripts
according to the review comments. And replace most of hard-coded
config by reading them from .config.
3. Unexpected build fail for gcc 4.7/trunk from crosstool-ng due to
unsupported ENDIAN_LDFLAG "-EL", which is used in "LDFLAGS_FOR_TARGET"
to build libstdc++. (LDFLAGS_FOR_TARGET seams not used in gcc 4.6).
Need more investigation.
Plan:
* Fix the binary build related bugs.
* Ramp-up on gcc.
Planned Absence:
* Jan 21-29, 2012 Chinese Spring Festival
Best regards!
-Zhenqiang
Hi,
I use pre-built version of linaro toolchain (got from http://people.linaro.org/~michaelh/incoming/binaries/) to build a uImage.
The build succeeded, but the uImage couldn't start.
The console hangs at:
Using FEC0 device
TFTP from server 10.193.100.158; our IP address is 10.193.102.233
Filename 'uImage_linaro'.
Load address: 0x70800000
Loading: #################################################################
#################################################################
#################################################################
#######################
done
Bytes transferred = 3193292 (30b9cc hex)
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.38-01026-gc9c8ead
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3193228 Bytes = 3 MB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Does anyone meet this before?
How can I fix it?
Thanks~~
Yours
Terry
* Started with some day-to-day activities in the team. Looking after the
proposals and the cbuild scheduler. Will start
Created problem log for scheduler problems, there is a link to it from the
jobs page. https://wiki.linaro.org/WorkingGroups/ToolChain/SchedulerProblems
* Worked on producing graphs for benchmark results using matplotlib.
Michael: Would it be ok to put my script in
linaro-toolchain-benchmarks/scripts?
* Kicked off some benchmarks with gcc-linaro-4.6-2012.01. To start with
coremark, eembc, denbench, pybench and spec2000. We will see what's there
after the weekend.
Variants: os-neon, o2-neon, o3-neon-novect and o3-neon.
/Regards
Åsa
== GDB ==
* Implemented, tested, and posted for discussion yet another version
of remote support for "info proc" and core file generation, this
time via accessing /proc files via generic file I/O primitives.
== GCC ==
* Tested and merged Revital's fix for LP #879725.
* Tested Richard's patch to help code generation for NEON strided
loads by enabled forward-propagation of subreg expressions. This
caused optimization failures on x86_64; investigated the root
cause and engaged in discussion on mailing list on potential fixes.
* Helped Ramana look into PR 43808 and PR 50313.
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
Continued work on 64-bit shifts. I've tidied up most of the nastiness I
had in my first attempt at this work, unified the logic into fewer
places, and fixed the one logic error that I knew about. I had a
mysterious reload bug that just wouldn't go away, but having stared at
it for some time I've decided that what I was doing wasn't the best
option in any case, and the new way seems to work. I still have the
problem that register-allocation prefers to allocate the values in
core-registers, even when it would seem to me to work better in NEON.
This maybe because the shift amount must be negated in some cases, and
there isn't a neon instruction for that.
Continued trying to use LAVA to do builds. Unfortunately this seems to
have hit against a lava-test bug. Filed as lp:915915.
Hi,
* built linaro binary toolchain using Michaels crosstool-ng environment:
* disabled multiarch and pkg-config
* uses eglibc 2.13 (due to RPC headers)
* using Linux kernel version 2.6.32.48 (longterm)
* debugged why /sbin/init fails when using the linaro binary toolchain:
* the loader and libc of the binary toolchain is build for armv7
* the binaries (init, busybox, ...) are linked against this glibc and
using the libdl-2.13.so of the binary toolchain
* it causes the boot to fails due to illegal insn caused by the dl
* built the minimal image for armv7-a:
* use the vexpress_defconfig of linaro 3.1 tree linux-linaro-3.1.git
(instead of the OE vesatilebp kernel)
* boots fine using the vexpress-a9 QEMU system model
* sato image (X and gtk+ apps) for armv7-a:
* Tremor (vorbis): inline assembly only supports ARM mode
quick workaround: undefine _ARM_ASSEM_ to fall back to C
* pulseaudio/libatomics-ops: inline asm that only supports ARM mode
quick workaround: use the latest version from upstream
* gtk+_2.24.8 fails due to the libstdc++ libtool archive
easy fix: delete the *la files (just like most of the distributors)
the *la files prevent the the binary toolchain from being "relocatable"
* sato image boots and shows the gui but the X resolution is higher and
the X cursor behaves strange (probably not a miscompile but a
difference of the linaro kernel)
Regards,
Ken