== Progress ==
* AARCH64 - gprof support.
Submitted GCC patches to generate profile call.
Also applied the review comments from Marcus and tested patches for
aarch64-none-elf.
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00597.html
* Setup a Ubuntu machine at Office.
Ran GCC testsuite with on openembeded/V8 model
ref: http://people.linaro.org/~hrw/oe/vekumar/.
This image has updated gcc and glibc and enables gprof.
During bootstrap GCC build failed due to space getting over.
Need to create a larger image.
* Looking at how to handle builtin_return_address when
-fomit-frame-pointer is enabled.
GCC saves frame pointer for the function alone where
builtin_return_address is used.
Callers of the function may not have set up the frame yet.
== Plan ==
* Continue gprof "-c" option support in binutils
* Continue handling builtin_return_address when -fomit-frame-pointer
is enabled.
* Continue gcc bootstrap and regression suite after creating a larger image.
== Progress ==
* 3.3 Release
- Running tests on Pandas and Calxeda, Ubuntu 12.04 and 12.10
- Chromebook arriving next week
- Calxedas died a couple of times this week for no reason (somebody else
turned it off?)
- Many bootstrap failures on 12.04: check-all, test-suite, etc on all
phases
- Fixing a bug that allows to bootstrap on Ubuntu 12.10
* EuroLLVM 2013
- Published the questionnaire results, wrote a post on the blog
- http://blog.llvm.org/2013/05/eurollvm-2013-paris-france.html
* Extra
- Studying C++11 atomics
== Issues ==
There's no way to tell when someone will turn the Calxeda server off, so
relying on its results or usability is folly. Not to mention that the
designers should have had a bit more care on the interface to power up and
configure nodes.
== Plan ==
* Spend the weekend testing on the Pandaboard with Ubuntu 12.10 and see if
the fix is good, commit
* Install Ubuntu on Chromebook arriving on Monday, run release tests on them
* Hope that Ubuntu 12.10 will be less hemorragic than 12.04 for the LLVM
release...
Short week (3 days)
== Progress ==
* Disable-peeling: got results vs reference, shared with team.
* Revert-coalesce vars: got results vs reference, showing regressions.
* Libsanitizer: committed upstream.
* Neon intrinsics: shared initial proposal of dejagnu-ization of my
existing tests.
* Branch reviews
* Internal support
== Next ==
* Disable-peeling: investigate regression on eon
* Revert-coalesce: discuss how to handle it with team
* Libsanitizer: enable on aarch64
* Neon intrinsics: continue improving crc with vuzp
* Neon intrinsics tests: continue dejagnu-ization
== Progress ==
* Four day week and traditional bank holiday cold slowed progress.
* Tested glibc memcpy patch on big endian and got it committed.
* Submitted some generic IFUNC patches for binutils upstream.
* Further work on AArch64 IFUNC support in binutils.
== Issues ==
* cbuild seems to not be doing much building at the moment.
== Plan ==
* Complete AArch64 IFUNC support and submit a patch.
* Look further at gdb bug if I get time.
--
Will Newton
Toolchain Working Group, Linaro
[three day week]
Progress:
* VIRT-49 [cp15 migration]
** lots of patch cleanup; nearly ready to submit but ideally
I'd like to test KVM migration with Andre's kernel changes first
** improved arndale setup by switching to USB hard disk; confirmed
I can build and boot my own kernel
* VIRT-50 [cp15 reset]
** it turns out that the VIRT-49 patches on their own break
reset handling for the KVM case, so we need to include VIRT-50
work in the same patchset. Fortunately it turns out to be a small
extension; patch done and tested, and will be submitted as part
of the VIRT-49 patchset
* misc
** discussions about early-printk in a virtual machine. I still think
it's important to be able to have a device tree binding to tell
the kernel where its early-printk uart is. Grant Likely said he
and Nico actually tossed this idea around in the past, it just
never got implemented.
Plans:
* VIRT-49/50: test against Andre's kernel timer save/load patches,
then submit
* more in-depth review and test of John Rigby's mach-virt and
aarch64 patchsets
-- PMM
Hi,
I'm running into an interesting problem with driver blobs when building
Android with the 4.8 toolchain:
E/libEGL ( 1219):
load_driver(/vendor/lib/egl/libEGL_POWERVR_SGX540_120.so): Cannot load
library: soinfo_link_image(linker.cpp:1635): could not load library
"libIMGegl.so" needed by "libEGL_POWERVR_SGX540_120.so"; caused by
soinfo_link_image(linker.cpp:1635): could not load library "libsrv_um.so"
needed by "libIMGegl.so"; caused by soinfo_relocate(linker.cpp:975): cannot
locate symbol "__aeabi_uidiv" referenced by "libsrv_um.so"...
__aeabi_uidiv is a libgcc.a function (Android doesn't have libgcc_s) - and
the blob makers didn't link libgcc.a properly, so it is understandable why
this would be missing.
However, Android's libc has an ugly but (up until now) working workaround
that is supposed to address this sort of issue.
It includes libgcc_compat.c, which comes down to
#define COMPAT_FUNCTIONS_LIST \
XX(__aeabi_uidiv) \
... (same for other libgcc functions)
#define XX(f) extern void f(void);
COMPAT_FUNCTIONS_LIST
#undef XX
void __bionic_libgcc_compat_hooks(void)
{
#define XX(f) f();
COMPAT_FUNCTIONS_LIST
#undef XX
}
Running nm on libc.so shows the symbol is actually in libc.so, and it seems
to be visible.
$ nm /system/lib/libc.so |grep aeabi_uidiv
0004f5d8 t __aeabi_uidiv
0004f680 t __aeabi_uidivmod
libsrv_um.so is linked to libc too, so it should see it...
$ objdump -x /vendor/lib/libsrv_um.so |grep libc.so
NEEDED libc.so
Can anyone think of a reason why this would work fine if the system is
built with the 4.7 toolchain, but break with 4.8?
My first thought was that 4.8 might have miscompiled the dynamic linker -
but the problem remains if I copy in /system/bin/linker from the 4.7 build.
ttyl
bero
Hi all,
You probably don't care, but here is a quick post (with pictures!) of the
EuroLLVM 2013 that just happened last week.
http://blog.llvm.org/2013/05/eurollvm-2013-paris-france.html
Linaro helped organize (mainly so I could get free booze in Paris), and it
seems that other people liked it, too.
If you're really interested in knowing more, let me know.
cheers,
--renato
== Progress ==
* SD card purchased dumped ubuntu for chromebook on sd card and configured
chromebook for development.
* Created newly released GDB 7.6 test suite results by running on
chromebook and x86 machine in native-none,native-gdbserver and
remote-gdbserver configurations
* Created GDB 7.5.1 test suite results by running on chromebook and x86
machine in native-none,native-gdbserver and remote-gdbserver configurations
* Created comparisons of gdb 7.6 test suite results in different
configuration.
* Public Holiday on 1st of May
== Plan ==
* Fill up the googledoc comparison sheets of gdb 7.6 test suite run in
different configuration on chromebook and x86.
* Fill up the googledoc comparison sheets of gdb 7.5.1 test suite run in
different configuration on chromebook and x86.
* Analyse difference between test suite results between gdb 7.5.1 and gdb
7.6.
* Pakistan General Elections 2013 might have to take a day off.
== Progress ==
* AARCH64 - gprof support.
Make GCC generate profile information (Completed).
Defined macros in GCC to enable frame return address and insert profile call.
Changed glibc to use generic gprof calls. Now gmon.out is generated
when run in openembedded on V8 model.
Used PROFILE_HOOK and generated mcount call using emit_library_call.
Misc
-------
1 May was a holiday.
== Plan ==
* Continue AARCH64 gprof support
* Post patches in GCC for profile and RETURN_ADDR_RTX
* Look at gprof "-c" option support in binutils
* Run gcc testsuite with changes on openembeded/V8 model.
Hi,
I tried compiling a hello-world program for cortex -a53/57 but, gcc does not recognize the mcpu option.
Here is my command ...
aarch64-linux-gnu-gcc hello_world.c -mcpu=cortex-a53 -o hello_world
Does the compiler support these options? I see that lib/gcc/aarch64-linux-gnu/4.8.1/plugin/include/config/aarch64/aarch64-cores.def do have the entries for cortex a53 & a57.
Thanks,
Kalai
== Progress ==
* Committed binutils testsuite fix for precise, should be green in cbuild now.
* Comitted binutils fix for ARM IFUNC issue.
* Various small binutils fixes for AArch64.
* Lots of rework of glibc memcpy patch, now up to v6.
* Integrated latest bionic string functions into cortex-strings.
* AArch64 IFUNC code and tests beginning to take shape.
== Issues ==
* None.
== Plan ==
* Another respin of glibc memcpy patch (last one?).
* More work on AArch64 IFUNC.
* May get time to look into gdb bug Peter found.
* 4 day week due to bank holiday.
--
Will Newton
Toolchain Working Group, Linaro
Progress:
* office move
* checking up on status of licensing issues with QEMU's softfloat
* cleaned up obsolete qemu blueprints in launchpad [Matt G-D is
going to finish the last bits of transferring the backlog to
JIRA where appropriate]
* booked travel/hotel for Connect Dublin
* reviewed John Rigby's mach-virt and aarch64 patches
* VIRT-49
** can run KVM with this code now, need to test migration proper
(requires kernel to support arch timer state save/load),
and clean up some TODOs and other cruft
** GDB is behaving oddly connected to QEMU's stub, which I think is
a GDB bug (LP:1175525) but may also be a QEMU side issue
Plans:
* VIRT-49 debug & patch cleanup
* NB: UK bank holiday next week, will be 3 day week for me
-- PMM
== Issues ==
* None
== Progress ==
* Short week (only 2 days)
* Libunwind AArch64 support:
- Did some fixes and cleanups after review.
- re-submitted upstream
* LRA on ARM and AArch64:
- Enabled LRA on trunk for ARM target
- build doesn't complete, investigation ongoing
* Internal meetings
== Plan ==
* Short week too
* Continue on LRA
== Progress ==
* EuroLLVM 2013
- Conference Mon~Tue
- Analysing questionnaire's response
- Writing a blog entry, reports
* Shorter week, low progress
== Plan ==
* Release
- Start testing version 3.2
- Check-out frozen 3.3 and run the same tests
- Make sure calxeda node is up to the task
- Buy a Chromebook for further testing (?)
I'll probably spend all my time worrying about the release, one way or
another...
Hi,
I'm trying to build the aarch64 tool chain from source on a Redhat machine. I see that build.mk in the crosstool package requires a few .deb packages. If I want to build this on a Redhat machine, what are the changes I have to do?
Thanks,
Kalai
Hi,
I am looking for pre-build (binary, tar) GCC for native ARM e.g. I need to
use in Angstrom FS and panda board to compile the code.
Thanks & regards,
Sukumar