On 21 November 2013 07:12, Karlsson, Magnus <Magnus.Karlsson(a)lsi.com> wrote:
> Just wondering if somebody could point me to a good document on how the heap
> reclamation algorithm works for memory allocated in a user space program
> using the regular malloc/calloc functions.
Section 7.1.3, whose sub-sections include: "Implementation of malloc()
and free()", "Tools and libraries for malloc debugging", and
"Controlling and monitoring the malloc package", of Michael Kerrisk's
"The Linux Programming Interface" (http://man7.org/tlpi/index.html) is
one of the better reads of which I'm aware. He recommends reading the
man pages for malloc_info, malloc_stats, mallopt, and mallinfo (among
others) for more information.
In the C language, reclamation of allocated memory is usually driven
by the application. When you free() some memory, internal structures
know the size of what was previously allocated at the given location
(i.e. what was given to you by malloc()) and simply release that back
into the heap. There are ways to tweak the allocation of memory.
== This week ==
- This week was mostly spent on coming up to speed on the Linaro
backport process
- Backport 202872 - Merged changes from trunk to Linaro branch
== Next week ==
- Complete backport of 202872
- Begin work on other assigned backports
== Future ==
No concrete plans yet.
---------- Forwarded message ----------
From: Mark Pupilli <mpupilli(a)gmail.com>
Date: 17 November 2013 14:07
Subject: condition_variable_any missing from libstdc
To: linaro-toolchain(a)lists.linaro.org
Hi,
I sent this message a week ago but I don't think I was subscribed to the
list correctly. Apologies if it is repeated (it doesn't show in the
archive).
I have a problem with my cross build of (Linaro GCC 4.8-2013.10). I get the
following runtime linker errors regarding condition_variable_any:
"relocation error: /usr/local/lib/librobolib.so: symbol
_ZNSt22condition_variable_anyC1Ev, version GLIBCXX_3.4.11 not defined in
file libstdc++.so.6 with link time reference"
If I examine my built version of libstdc with readelf I get the following
output:
$ readelf -s ./src/.libs/libstdc++.so.6 | grep condition
10383: 000c58d8 68 FUNC LOCAL DEFAULT 11 _ZNSt15error_conditionC1E
10818: 000c58d8 68 FUNC LOCAL DEFAULT 11 _ZNSt15error_conditionC2E
10837: 000c5944 40 FUNC LOCAL DEFAULT 11 _ZNKSt15error_condition8c
10942: 000c591c 40 FUNC LOCAL DEFAULT 11 _ZNKSt15error_condition5v
Where as with the apt-get installed 4.6 version of the toolchain shows:
$ readelf -s /usr/arm-linux-gnueabi/lib/libstdc++.so.6 | grep condition
777: 000523b1 12 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
929: 000522f1 104 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
1037: 000523b1 12 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
1198: 000522f1 104 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
1686: 00052385 14 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
2166: 00052359 12 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
2438: 00052359 12 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
2685: 00052365 16 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
3186: 00052395 26 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
3448: 00052395 26 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
3643: 00052375 14 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
(Which is still missing anything to do with condition_variable_any, but
given that my native 4.8 compiler doesn't contain this symbol either and my
code builds and runs natively, I assume this is how it should be).
Here is my build's version information:
$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/mark/arm-linux-gnueabi-4.8.2/libexec/gcc/arm-linux-gnueabi/4.8.2/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../gcc-linaro-4.8-2013.10/configure
--target=arm-linux-gnueabi --prefix=/home/mark/arm-linux-gnueabi-4.8.2
--with-local-prefix=/home/mark/arm-linux-gnueabi-4.8.2 --disable-nls
--enable-shared --enable-multilib --disable-decimal-float
--enable-languages=c,c++
--with-mpfr-include=/home/mark/gcc-4.8-arm-linux/gcc-build/../gcc-linaro-4.8-2013.10/mpfr/src
--with-mpfr-lib=/home/mark/gcc-4.8-arm-linux/gcc-build/mpfr/src/.libs
--enable-clocale=gnu --enable-threads=posix --enable-__cxa_atexit
--disable-libstdcxx-pch --with-system-zlib
--with-headers=/home/mark/arm-linux-gnueabi-4.8.2/include
--with-libs=/home/mark/arm-linux-gnueabi-4.8.2/lib
--enable-libstdcxx-threads --enable-libstdcxx-time
Thread model: posix
gcc version 4.8.2 20131014 (prerelease) (Linaro GCC 4.8-2013.10)
I configured libstdc++-v3 respectively as follows:
$ ../gcc-linaro-4.8-2013.10/libstdc++-v3/configure --host=arm-linux-gnueabi
--prefix=/home/mark/arm-linux-gnueabi-4.8.2/ --enable-multilib
--enable-shared --disable-nls --disable-libstdcxx-pch
--enable-libstdcxx-threads --enable-libstdcxx-time
I assumed the relevant entries to enable C++11 threading and condition
variables etc would have been --enable-libstdcxx-threads
--enable-libstdcxx-time. I must be missing some other options or have done
something else wrong. Any suggestions?
thanks,
Mark
== Progress ==
* Short week
- Two days off due to a messy implant bloating my face
- Should be better on Monday
* Cambridge LLVM Day, Cambridge University Computer Lab
- Presented the status of the auto-vectorizer in LLVM
* Releasing candidate 1 of LLVM 3.4
- All tests green, running benchmarks
- http://people.linaro.org/~rengolin/llvm/
* Buildbots
- Adding Chromebook self-hosting (fixing MCJIT tests)
- Adding Chromebook test-suite (fixing ClamAV)
- Will turn off the old Chromebook and re-install it for benchmarks
- Will add an Odroid XU in pair with the community one to be added next
week
* Background
- Patch reviews, discussions
* EEMBC rgbcmy implementation requires extensive changes to the compiler
- Will deal with them on the background over the next months
- While checking other EEMBC problems
== Plan ==
* Continue the 3.4 release
* Look at vectorization pragmas
* Look at other EEMBC results
== Progress ==
* Committed a couple of gdb patches
* Debug malloc to a working state, performance improved
* First version of glibc aarch64 ifunc support
* Found a couple of bugs in binutils aarch64 ifunc support
== Issues ==
* Missed two days due to illness
* Power cut and broadband outage on Wednesday afternoon
== Plan ==
* Respin and submit glibc docs patches
* Submit glibc aarch64 ifunc code
--
Will Newton
Toolchain Working Group, Linaro
Hi, All
Under this site
http://releases.linaro.org/13.09/components/toolchain/binaries/,
there are many files released. but do we have any description on the file
naming rules?
Sorry for my simple question, I just want to know what the files are used
for. which one I should select when I need to use toolchain.
Like the files below, I can guess that aarch64 means that it will generate
files run on aarch64 platform, but I can not guess what's the difference
between linux and none, and not know what's the difference between gnu and
elf.
So if you have any wiki/link about the the naming rules or description
about the file,
please share me.
crosstool-ng-linaro-1.13.1-4.8-2013.09-01.tar.bz2
crosstool-ng-linaro-1.13.1-4.8-2013.09.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_runtime.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_src.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-20130912_win32.exe
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_runtime.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_src.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip
gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_runtime.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_runtime.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_src.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip.xz
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09-20130912_win32.exe
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.bz2
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.xz
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_src.tar.bz2
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip.xz
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.bz2
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.xz
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip.xz
--
Thanks,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/pipermail/linaro-validation
Hi toolchain gurus,
I am about to start some projects working with CortexMx devices and am
wondering if anyone has an opinion on which toolchain(s) I should
use/investigate?
Being a fan of Linaro, my first instinct would be to use cbuild2 to
build an arm-none-eabi- toolchain from a 4.8.x tree. But looking
around I can't help notice https://launchpad.net/gcc-arm-embedded.
Does anyone know if gcc-arm-embedded has things the Linaro toolchain
doesn't wrt Cortex M0, M3, and M4 device/instruction support?
Best regards,
Trevor
-------- Original Message --------
Subject: [Bug target/59216] [ARM] negdi*extendsidi regression
Date: Wed, 20 Nov 2013 18:06:14 +0100
From: christophe.lyon at st dot com <gcc-bugzilla(a)gcc.gnu.org>
To: Christophe LYON <christophe.lyon(a)st.com>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59216
--- Comment #2 from christophe.lyon at st dot com ---
Basically, the working code does:
asrs r3, r2, #31
negs r2, r2
sbc.w r3, r3, r3, lsl #1
while the failing one does:
negs r2, r2
asrs r3, r2, #31
--
You are receiving this mail because:
You reported the bug.
Hi LAVA folks,
I don't know if you guys know, but Android is moving to LLVM for the next
release or so. As such, we'll need to do a lot of testing between now and
next release to make sure each component can be compiled (and runs
correctly) with LLVM on an incremental basis.
We're trying to come up with a way for remotely testing the Linux kernel
booting on ARM devices, more specifically an Android stack, and I'm finding
it hard to do that with my home equipment. Doing that in LAVA would be
ideal, and I know the Android team does it already, but our constraints
could be a little different.
Basically, there are two fronts:
1. Building Android components with LLVM, using a GCC-compiled kernel
booting on an ARM board, in LAVA. This is something we should work
internally on how to do it, and it'll be between Android, LAVA and
Toolchain groups.
2. Building the Linux kernel with LLVM, and using a GCC-compiled image
(like stock CyanogenMod) to test the kernel. We don't have such a kernel
(many patches), but the LLVMLinux guys do, and that's where they come in.
On the second case, the topic of this email, we'd have to liaise with them
to fire jobs at LAVA from their own infrastructure (originally, manually
only), and that might need some thinking. But ultimatelly, we want to have
those jobs running on LAVA, so that later on we'd be able to have a third
layer: Linux+Android built with LLVM with the same system level tests.
Since the LLVMLinux guys don't have access to much ARM hardware, and since
it's easier for us to scale (or to re-define) hardware requirements, having
them running on LAVA makes even more sense.
Is this something we can do? Is this being done already? Is this just a
question of legal/corporate decision, or is there any technical issues we
have to look into?
Android folks,
It might make more sense if you guys just grab their kernel and build the
Android system based on that internally, so that we don't need external
access to job submissions in LAVA, but that would mean work from you guys
to patch it up, and that might not be in the roadmap for the next months.
Is that a feasible route?
cheers,
--renato
= Progress ==
* Created Cards for the infrastructure Team TODO list.
* Finished Cbuildv2 support for building GDB binary tarballs.
* Got Arch linux up on Odroid XU board again, seems stable, did a
build and test run.
* Experimented with lava-tool.
* Tried to get GCC trunk building native on aarch64 for libsanitizer
patch testing.
* Upgraded gmp to 5.1.3 in infrastructure/ to work around a configure
bug triggered by crouton native builds on a chromebook.
* Setup chromebook slaves in new toolchain build farm.
* Started adding support to Cbuildv2 to handle git URLs with a user
name, ie.. git(a)staging.git.linaro.org to work around git repo
problem.
== Plan ==
* Finish support for user names in URLs.
* Continue on remote testing support.
* Keep trying gcc trunk on aarch64 native.
* Fix git repo.
== Issues ==
* GCC git repo hasn't been auto updating the svn branch of
linaro-4.8-branch. It used to work... updating manually is now
broken as well.
* Somehow qemu snapshots tarballs are overwriting the toolchain
directories on snapshots.linaro.org.
* I don't think lava-tool is going to be useable for toolchain
testing, as it only queues up an executable test case to be run
later, whereas GCC expects the test to get run right away.
One day off
== Progress ==
* Prepared 4.7 and 4.8 2013.11 releases. Some delay because of board
crashes and disk full issues.
* Aarch64: committed 'frame grows downward' patch. This removes a
dependency for libsanitizer and libssp.
* libsanitizer on Aarch64: blocked by GCC trunk not bootstrapping
currently on Aarch64 HW (reported by Rob)
* Looked at cross-build failures of trunk after new
-fisolate-erroneous-paths. Ramana pointed me to Marcus' glibc patch,
and I could switch my builds from eglibc to glibc.
* cross-validations: updated list of configurations built&tested after
discussion with Richard during Connect.
== Next ==
* Announce 4.7 and 4.8 2013.11 releases
* Continue investigating 'extended neg' fix (aka tar regression)
* Look for patches to fix AArch64 bootstrap, so that we can test libsanitizer
One day off.
== Issues ==
* Various cbuild issues:
- disk full, boards down and benchmarks launched on different boards
== Progress ==
* LRA on AArch32:
- Proposed a ARM backend fix for the Fortran issue
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01997.html
- Performance analysis ongoing
* Merge reviews and backports.
== Next ==
* Continue on LRA
== Progress ==
* Wrote ARM and Thumb stub handlers for simd, vfp and coprocessor
instruction recording.
* Read documentation on VFP and Neon register set to figure out a register
recording method.
* Follow up on upstream patches.
* Investigating a un-handled instruction test suite failure in arm process
record.
* 9th/10th Muharram Public holiday on Thursday and Friday.
== Plan ==
* Fix failures in arm process record due to un-handled instruction.
* Get started on writing handlers for coproc, vfp and simd instructions.
== Issues ==
* None.
== Progress ==
* One day (Nov. 15) off.
* Misc update for Linaro crosstool-ng
- Use newlib-linaro-2.0.0-2013.11-1.
- Update fortran support related scripts and configs according to
Matt's comments.
* Propose to support S2_<op1>_<Cn>_<Cm>_<op2> system register in AARCH64 GAS.
- Yufeng followed-up it and added full TRACE registers support.
* Investigate heuristic to tune ifcombine (TCWG-313)
- Got some new fails in regression tests since some optimizations
can not get the expected result.
- Collect Spec2k INT result. Overall there is no changes. But there
are -2 - 1% changes for several cases.
- PGO tests are ongoing.
== Plans ==
* Continue on CCMP.
* Continue on ifcombine tuning.
== Progress ==
* Preparing presentation on auto-vec for LLVM
- For Cambridge LLVM Day next Monday
- If accepted, also for FOSDEM 14
* Tracing strided access changes needed in auto-vec (PR17677)
- Reading the paper, preparing a reference implementation
- Discussing details and preparing the LLVM code to introduce it
- After a few attempts, it's clear that the code is not yet ready to cope
with the changes
- I'll have to work on the surrounding code to re-factor it for more
robust integration
- As well as triming some other edges (like pragmas) to help implement it
* Planning Android builds
- Trying to get a reference platform (most likely the new Arndale)
- LLVMLinux folks will help streamlining a kernel package for it
* Connect reservations, booking flight, etc.
- All done!
== Plan ==
* Monday at Cambridge LLVM Day at CUCL
* 3.4 Release testing
* Looking at vectorization pragmas and general structure of the memory
dependency checks
== Progress ==
* Fix ld testsuite on mainlne
* More malloc debugging and refactoring
* glibc patch review
* Investigate gdb hardware breakpoint issues
== Issues ==
* Didn't get much done on Friday due to sick baby
== Plan ==
* malloc
* Follow up glibc docs patches
* Further investigate gdb hardware breakpoint issue
--
Will Newton
Toolchain Working Group, Linaro
Short week: 2 days off after Connect.
== Progress ==
* LP 1243656: reverted commit which causes a regression in GNU tar's tests.
* Committed Kugan and Zhenqiang's backports to our branch
* Status on backports: ILP32 support missing from binutils is blocking
quite a few GCC backports (because of dependencies between commits)
* Some problems building trunk since Nov 5th (failures in eglibc)
== Next ==
* Make 2013.11 releases
* Continue working on GNU tar problem: find a proper fix.
* Commit 'aarch64 frame grows downward' patch if Richard approves it.
* Check status of aarch64 lib sanitizer branch if Rob manages to have
it build & execute tests
* Check Neon intrinsics testsuite status with Rob
== Progress ==
* Monday off for recovery from Connect.
* Created git_revisions branch for refactoring
* Added verified and correct --help and --usage text.
* Error check for spurios '=' after --<switch>
* Add toplevel test.sh for testing cbuild2.sh commands
* Fix get_URL and checkout to support git revisions.
* Improve dryrun to prevent grepping missing files.
* Added glibc support to cbuild2.
* Cleaned up merged cbuildv2 remote development branches
* Started cbuild2 bisect.
== Plan ==
* Merge glibc support upstream
== Issues ==
* None
== Progress ==
* Monday and Tuesday off for Jetlag recovery.
* Arm process record:
- Updated Patches for all fixes and features.
- Performed testing in arm native and remote configuration.
- Performed regression testing on arm and x86.
- Submitted all new patches after updates.
* Started gdb.reverse test suite failure investigation and open new Jira
issues accordingly.
* Started work co-processor instructions decoding for arm process record.
== Plan ==
* Continue work on co-processor instruction decoding for arm process record.
* Respond to upstream suggestions on patches sent previously.
== Issues ==
* Binaries build FAIL in cbuild, but OK in local build.
== Progress ==
* Misc update for Linaro crosstool-ng
- Update newlib to 2013.11.
- Modify scripts to meet the check of A-profile multilib support.
- Add fortran/libfortran support for bare metal build.
- Fix multi-lib conflict issue in local patch
- A refer A-profile bare metal build is shared at
http://cbuild.validation.linaro.org/snapshots/gcc-linaro-arm-none-eabi-4.8-…
* Update conditional compare patch according to comments.
* Investigate heuristic to tune ifcombine (TCWG-313).
== Plan ==
* Fix the binaries build FAIL issues.
* Continue on CCMP.
* Continue on ifcombine tuning.
== Planed leaves ==
* Nov. 15 - 16: Team event and HelloGCC in Beijing.
== Progress ==
- Looked into Cbuild2 and current benchmarking scripts
- Talked to Rob to understand the requirements and plan for next 2 weeks
- Backported gcc testcase fix that causes regression in Linaro 4.8 for
armv5te.
== Plan ==
- Taking leave next week.
- Start with benchmarking scripts after that
Worked from AMD Austin.
== Progress ==
* TLS based libssp support.
Solved segmentation faults in clone and fork tests regressing from
the patch I wrote. Ran glibc tests.
Two tests still fail, tst-cancel-17.c and tst-memqueue8.c. They both
use pthread_cancel and with my patch they time out. Debugging it to
find the cause. Informed Maintainer about my status and got some
advice to debug.
== Plan ==
* Taking vacation next week.
* But will continue send out gcc patch for libssp.
* reinstall ubuntu on my laptop
== Progress ==
* Enabled building GDB in all Cbuildv2 builds for --build all.
* Added support for Cbuildv2 to to build GDB source tarball.
* Got Canadian Crosses building via Cbuildv2, although I have to
apply a one line patch, which I was trying to avoid.
* Enabled Canadian Cross builds via Jenkins.
* Source and binary snapshots builds via Jenkins now getting copied
to snapshots.linaro.org.
* Got started migrating Christophe's neon intrinsic test cases to
GCC testsuite.
* Added DejaGnu 'linaro' branch to Cbuildv2 infrastructure so
the new baseboard files are available for Jenkins builds.
* Applied Christophe's libsanitizer patch on aarch64 APM board and
tried to get GCC to compile. Unsuccessful so far.
* Installed crouton 'saucy' on new HP Chromebook 11.
* Installed Fedora 19 on Samsung Chromebook.
* Started adding support to Cbuildv2 for building LLVM and
Clang and other components. I wish they all used autotools. :-)
* Got Gerrit working for GCC and Cbuildv2. The LAVA team has been
very helpful, but the setup docs miss way too many critical
details.
== Plan ==
* Figure out how to gpg sign the tarballs cbuildv2 is producing in
a secure manner.
* Finish adding support for building GDB binary tarballs.
* More work on neon intrinsics test cases.
* Work with new team member Mike to help him get up to
speed on all things Linaro.
* Try to get GCC trunk to build on aarch64.
* Off to the "Hacker's Conference" out here in Santa Cruz, back
home late Monday night.
== Issues ==
* Eglibc defines caddr_t as a typedef, where auto-host for a
Canadian Cross defines caddr_t, so stage2 fails to build.
* Sucked up all the disk space in the toolchain_cloud instance, so
all Jenkins builds are not working.
* We'd like to rename Cbuildv2 to something else, suggestions
welcome. :-)
