Hi!
* Ran eembc, coremark, denbench and spec2k on the ursas with the latest of
the Linaro and FSF series. The variants used were o3-neon and
o3-neon-novect.
I first got a c++ related build error when using 4.4.x compilers, the was
error caused by symbol versioning. Michael's explanation: "We want to use
the gcc-4.4.5 libstdc++ when building and running. However, when running
c++ itself, it links in /usr/lib/libppl_c.so, which was built with the host
4.5 compiler, which needs the 4.5 libstdc++!"
The work around is to remove the LD_LIBRARY_PATH from build.mk (the
gcc-%/benchmarks.stamp target) and run the C only tests.
* Continued documentation of running benchmarks:
https://wiki.linaro.org/AsaSandahl/Sandbox/RunningBenchmark. Tips of more
efficient ways of doing things are always welcome.
* Collected the results for SPEC2K runs with "train" and "ref" data sets. I
did -o2 and -o3 runs on a panda with the two data sets. The results for -o2
and -o3 looks almost the same though. I will double check the "*build.txt"
files from the benchmark runs, and if needed do a complementary run.
Best regards
Åsa
Dear All,
I am using arch/arm/configs/vexpress_defconfig to configure and build Linux
Kernel 3.1.1
http://launchpad.net/linux-linaro/3.1/3.1-2011.11/+download/linux-linaro-3.…
and then if I booth the zImage crated on Linaro QEMU
http://launchpad.net/qemu-linaro/trunk/2011.10/+download/qemu-linaro-0.15.5…
,it works properly.
But if i enable the LPAE support in the config file, the kernel builds and
when I boot the kernel image on QEMU, it just prints the output as :
Uncompressing Linux... done, booting the kernel.
And, then it hangs ... Can anyone please tell how to fix this issue?
Looking forward to your reply.
Thanks and Regards,
Jubi
I discovered some excessive memory usage in gas recently when
defining macros. It turns out that this is a weird implementation
feature rather than a bug.
This patch has a possible fix for the issue, but I'd be interested
in people's views before I go so far as cleaning it up and
discussing it upstream.
Cheers
---Dave
Dave Martin (1):
gas: Allow for a more sensible number of macro arguments
gas/as.c | 17 +++++++++++++++++
gas/doc/as.texinfo | 9 ++++++++-
gas/hash.c | 5 +++--
gas/hash.h | 1 +
gas/macro.c | 22 +++++++++++++++++++++-
gas/macro.h | 1 +
6 files changed, 51 insertions(+), 4 deletions(-)
--
1.7.4.1
[Jubi, I'm afraid this is the second copy of this you'll see, because
you accidentally sent your reply to linaro-toolchain-request rather
than to the actual mailing list, and so my first reply was misdirected.
This reply is to the correct list address...]
On 22 November 2011 13:28, Jubi Taneja <jubitaneja(a)gmail.com> wrote:
> Thanks for your reply. Please find the response inline ..
> On Tue, Nov 22, 2011 at 6:44 PM, Peter Maydell <peter.maydell(a)linaro.org>
> wrote:
>> On 22 November 2011 13:06, Jubi Taneja <jubitaneja(a)gmail.com> wrote:
>> > But if i enable the LPAE support in the config file, the kernel builds
>> > and
>> > when I boot the kernel image on QEMU, it just prints the output as :
>> >
>> > Uncompressing Linux... done, booting the kernel.
>>
>> Does your kernel boot OK on real hardware?
>>
>> (ie, is a kernel with LPAE support expected to boot on a CPU like the
>> A9 which doesn't have LPAE?)
>
> Yes, it is expected to boot ARM Cortex A15 CPU.
The A9 and the A15 are different CPUs. QEMU currently supports
only the A9. This is why I asked if this kernel boots OK on real
Versatile Express A9 hardware.
>> Also if your config/kernel command line don't turn on earlyprintk it's
>> worth enabling this as it usually gets you better diagnostic messages
>> for early kernel boot failures.
>
> Ok, I will try to check this. But, unfortunately now I again tried enabling
> LPAE in config file and the current status is that when I boot the kernel
> image on Qemu. it simply hangs. It now don't show that message of
> Uncompressing kernel.. I am trying to debug it using gdb, but could not find
> much. Please guide me how shall I proceed ahead.
If you've turned on kernel support for the Versatile Express A15
rather than the Versatile Express A9 then this is expected behaviour:
the VE-A15 has a different memory layout and in particular the serial
ports are in a different place. So if you try to boot the kernel on
a VE-A9 system (which is what QEMU is modelling) then it will display
nothing because the kernel is trying to write to UARTs which aren't
there.
What are you actually trying to achieve here?
-- PMM
Continued looking at constant reuse optimizations, as a background task.
I've fiddled with the costs a bit more to remove false positives.
Continued benchmarking different generic tuning ideas. With each test
run taking most of a day this is slow going.
Took Michael's rootfs that is used for all the toolchain testing and
benchmarking, unpacked it, and repacked it so that it is compatible with
"linaro-media-create", then tested that I could use it to run tests on
LAVA successfully. I was hoping to use this for extra benchmarking
bandwidth, but there's a permissions problem in the LAVA website
software that means it's not yet possible to post private results to the
system, so no proprietary benchmarks yet. I can still continue
pipe-cleaning my process, and maybe run some benchmarks without actually
reporting the results (or perhaps posting them somewhere write-only).
Begun work on adding GCC support for 64-bit shifts with NEON. This is
not quite as simple as it ought to be because a) it's inefficient to
move a value to NEON registers just to do a shift, so it needs to detect
where the value is, and b) right shifts are encoded as left shift by a
negative amount, and negative shift amounts are normally considered
undefined behaviour.
RAG :
RED : None
AMBER: Worried about trunk failures with test runs. Number of
testsuite failures after the atomics merge has increased - more below.
.
Task Planned Estimated Actual
Historical
~~~~~~~
Connect 2011.q4
preparation 28/10/2011 28/10/2011
28/10/2011
Linaro Tasks
~~~~~~~~~~~~
Fully Investigate the O3
performance
regressions 31/01/2012
Writeup on the optimizations 31/12/2011
enabled with PGO
==Progress===
* Debugged the LTO failures for some time this week - not much progress.
* The bootstrap failure with trunk turned out to be the same problem
as with the CFG not being updated properly with some of the
shrink-wrap patches from Alan M . This was fixed on trunk later on
Monday.
* Tested atomics fixes but the test results are overall looking ugly .
Need to do some more debugging. Discovered GDB was broken for single
stepping in ARM atomic sequences - Filed bug report
https://bugs.launchpad.net/gdb-linaro/+bug/892008 here.
* Looked into the vmul / vmla issue for a bit - did some experiments.
Need to write these up and follow up .
=== Plans ===
* Commit the vcvt fixed point patch.
* Finish experiments with the vmla stuff and find out more about this.
* Finish debugging the LTO failures with PGO bootstrap.
* Some research into the O3 perf issues.
Absences.
* Dec 19 - 31st Dec - Tentatively booked
== GDB ==
* Ongoing work on support for cross-platform core file generation.
== GCC ==
* Investigated Launchpad bugs:
#889984 binaries: should step across helper functions
#889985 binaries: can't step out of helper functions
#890764 4.6-11.11 seems to misdetect some files as system header and
implicit extern "C"
== Misc ==
* Gave talk on Linaro at the IBM Germany Technical Expert Council
fall meeting.
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
Sent the patch which implements register pressure estimation in SMS to
the gcc mailing list as RFC.
I looked at some of the regressions in libav and intend to continue
with that this week.
== Last week ==
* Caught up on lots of email.
* Looked into the SMS regression that Revital found. Turned out to be
caused by the ARM backend not modelling the VMLA fast accumulator path.
Need to know how the path actually works before modelling it
(the docs aren't clear).
* Continued to look at -fsched-pressure.
Richard
Summary:
* Create crosstool-ng patches and build embedded toolchain on ubuntu-8.04.4.
Details:
* Crosstool-ng patches
* Update old patches according to Michael's comments and revise them
according the guideline.
* Create patches for nls option, newlib and gdb.
* Try to build embedded toolchain on ubuntu-8.04.4. It works after
installing all the dependence libraries.
Plans:
* Upstream the patches.
* Build and test.
Thanks!
-Zhenqiang
