== GDB ==
* Ongoing work on support for cross-platform core file generation.
Posted a new design proposal to the mailing list to include not
only "info proc mappings", but *all* "info proc" commands. This
would involve a remote protocol command to read arbitrary proc
files, instead of a specific command to retrieve the memory map.
* Investigated Launchpad bug:
#891970 msp430-gdb segmentation fault with target remote
== GCC ==
* Patch review week.
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
Worked on adding support for 64-bit NEON integer shifts. I have this
working now, although I'm still not very happy about how the register
allocator chooses which mode to use - it prefers core-registers if the
values start or end in core-regs, even though moving to values to NEON
registers might be more efficient (general 64-bit shifts in core
registers require several instructions). I've also had to mark the CC
register clobbered in all cases, even though it only gets clobbered in
some of them, which might be necessary, but isn't very satisfactory.
The NEON shifts work showed that 32->64 bit extends could be done better
also. This hasn't been a great problem up to now, but the shift amount
(in particular) is typically a 32-bit value and yet needs to be
zero-extended to 64-bit for NEON's purposes. Right now, GCC prefers to
extend the value in core-registers, and then copy it to NEON. This
works, but burns another core-register - a scarce commodity - so I think
it would be better to copy it first, and then extend it after. NEON has
instructions for this, so I'm investigating how to get the compiler to
do it (this is all strictly post-combine, so the usual options are out,
and the register allocator has to be allowed to do it the old way in the
case where core-regs really are the best option, so it's tricky).
Summary:
* Upstream crosstool-ng patches.
* Create windows install package from installjammer.
* Investigate link issues.
Details:
* crosstool-ng patches.
* Patches for newlib extra config, gdb extra config, pch, nls option
are committed to crosstool-NG upstream.
* The dependant library patches are in discussion.
* Learn installjammer and integrate it to scripts to create windows
install package.
* Investigate warning message from link when linking the prebuilt zlib
for migw32 host.
It might be OK with static link, but migh fail with dynamic link on windows.
For i586-mingw32[msvc] host, lots of messages like
libtool: link: Could not determine host path corresponding to ...
For i386-mingw32 host: In addition to the message in i586-mingw32
build, output the following message
*** Warning: linker path does not have real file for library -lz. ...
Plans:
* Build and test.
Absences:
* Nov 29, 30: Trainings.
Thanks!
-Zhenqiang
Hi,
Good news -- I just built a version of ICS with the current version of
linaro-gcc.
Panda build here:
http://people.linaro.org/~bernhardrosenkranzer/boot.tar.bz2http://people.linaro.org/~bernhardrosenkranzer/system.tar.bz2http://people.linaro.org/~bernhardrosenkranzer/userdata.tar.bz2
Use linaro-android-media-create as usual to install.
This is not yet a build that we can reproduce inside android-build
because I've had to cheat by swapping out linkers in a couple of
places (just using current binutils the way we normally do produces a
build that doesn't boot, using binutils built from the AOSP source
release works, but the prehistoric linker doesn't know about "dmb st",
can't link u-boot, can't link the kernel, and strangely enough can't
link some components of ICS - apparently the binaries they ship have
some extra patches in).
But the good news is that every part is built with our compiler -
there's nothing in the way of using that (aside from the code
insanities I've already fixed).
I'll work on sorting out binutils now...
ttyl
bero
Hi,
I've spent most of my time to dig into OE. First I started with OE
(classic); then realized that OE-core is where the future happens and
switched to it. I've set up a build system and got a ARM minimal image
to build that boots in QEMU *yay*. In parallel I've been reading the
manual and looked into the receipts to find out what toolchain they are
using (gcc-4_6-branch plus patches). Next step is to get the OE-core
built using the Linaro-GCC.
Regards
Ken
== This week ==
* Looked at the MIPS _unpack_d bug. libgcc.a did have a definition,
and Michael couldn't reproduce with his build, so the bug report
is now marked as Incomplete.
* Backported patch for PR 48190 to upstream 4.6 and 4.5.
* Reviewed Revital's SMS register-pressure patch.
* More on -fsched-pressure. I now have a version that I'm happy with
as far as ARM goes, in that it usually seems to produce code that is
no worse than the better of currect -fsched-pressure and current
-fno-sched-pressure. (I'm sure there's a better way of saying that.)
In some cases it is better than both.
* Continued trying to catch up on mail.
== Next week ==
* Clean up the -fsched-pressure code (it's still in its "experimental mess"
state). Try it on Power.
* Resurrect vzip and vunzp patch after Richard E said he wouldn't object.
Richard
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
