== Progress ==
* Releases (CARD-1431 2/10)
- Spinning RC4, final, all green
* Buildbots (CARD-1823 1/10)
- Adding new quick Thumb2 non-NEON bot
- Adding new full self-hosting Thumb2 bot
* Libraries (CARD-1831 1/10)
- Trying to build a soft-float compiler-rt test-suite
* Sanitizers for AArch32/64 (CARD-1753 4/10)
- Investigating/fixing broken sanitizer bots (4 failures)
- Investigating other sanitizer failures on Junos
- More planning on TSAN, ASAN
* Background (2/10)
- Code review, meetings, discussions, etc.
- Reviewing the remaining EuroLLVM papers
- More LLDB planning
== Plan ==
* LLDB meeting with Google
* EuroLLVM final paper review meeting
* Continue building test-suite with Compiler-RT, libc++
* Continue help on ASAN/TSAN
* Try our first sprint planning...
# Progress #
* aarch64 gdb, TCWG-652, [5/10]
** TCWG-653: triage fails in aarch64-linux gdb testing, both native and
remote. Nearly done.
** TCWG-670: Clean up GDB testsuite for syscall catchpoint first.
Ongoing.
** TCWG-672: GDB can't unwind from glibc with the expected function name
if glibc is stripped. Nearly done.
** Committed two patches upstream fixing two fails on aarch64-linux
target.
** Clean up arm and aarch64 bug reports on sourceware.org bugzilla.
* fsf gdb patch review [4/10]
** Reviewed Omair's two process record GDB patches.
** Reviewed one patch may cause fails on remote testing.
* misc [1/10]
** 1x1 with Ryan.
** With Bernard's help, set up ssh access to linaro servers.
# Plan #
* All cards under TCWG-652.
* Move out of temporary apartment to a rented one on Friday.
--
Yao
Go away where ? ABE just uses whatever triplet you give it. I commonly use just arm-linux-gnueabi for example. If you don't specify 'none', it shouldn't appear anywhere. If it does, let me know and I'll fix it.
- rob -
-------- Original message --------
From: Christopher Covington <cov(a)codeaurora.org>
Date: 02/26/2015 2:52 AM (GMT+07:00)
To: linaro-toolchain(a)lists.linaro.org
Subject: Debian Multiarch Tuple Style Naming With ABE
Hi,
I recently built with ABE for the first time. It's pretty slick.
Is there a way to make the vendor string (the "none" in
"arm-none-linux-gnueabihf-*") go away? It breaks my scripts without appearing
to add value.
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Holiday Friday [2/10]
catomics - TCWG-436 [2/10]
* Fixed broken benchmark-against-sysroot code in scripts
* Built a lot of sysroots
Juno cache effects - LDTS-1238 [4/10]
* Quite a bit of reading and learning some more perf and other tools
* Formed a few hypothesis, started testing
* Looking promising, but I find these things often go wrong, so we'll see
Misc [2/10]
* Featuring first successful Jenkins run of all of SPEC2006
=Plan=
Make sure I've really fixed the last sysroot bug, actually run
benchmarks on catomics
Attempt to close out the cache effects issue
Carry on with Jenkins
Hi,
I recently built with ABE for the first time. It's pretty slick.
Is there a way to make the vendor string (the "none" in
"arm-none-linux-gnueabihf-*") go away? It breaks my scripts without appearing
to add value.
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi,
I am trying to port the Boost.Context library (from www.boost.org) to aarch64 gcc and have come across a gnarly problem.
Boost.Context essentially does co-routine style context switching. It has a structure f_context which it uses to save and restore contexts. The structure f_context contains both integer (x0..xN) and floating point VFP (d8..d15) context.
The function jump_context switches contexts
typedef struct f_context *f_context_t
extern void jump_context(fcontext_t *old, f_context_t new, bool save_fp);
So this jumps to a new context returning the old context in *old. If save_fp is set the floating point context must be saved because the application uses floating point. Otherwise the save and restore of the floating point context may be ignored.
So, essentially, to save the old context it does
jump_fcontext:
# prepare stack for GP + FPU
sub sp, sp, #0xb0
# test if fpu env should be preserved
cmp w3, #0
b.eq 1f
# save d8 - d15
stp d8, d9, [sp, #0x00]
stp d10, d11, [sp, #0x10]
stp d12, d13, [sp, #0x20]
stp d14, d15, [sp, #0x30]
1:
# save x19-x30
stp x19, x20, [sp, #0x40]
stp x21, x22, [sp, #0x50]
stp x23, x24, [sp, #0x60]
stp x25, x26, [sp, #0x70]
stp x27, x28, [sp, #0x80]
stp x29, x30, [sp, #0x90]
However, there is a problem with this because gcc may store integer value in floating point registers around a function call.
So, I have no way of knowing whether it is actually necessary to save/restore floating point context.
Even worse applications using Boost.Context may be completely borken if they assume it is safe to call jump_context with save_fp == 0.
Any suggestions?
Ed.
== This week ==
* Released Linaro 4.8 and 4.9 February 2015 release (2/10)
* Vector Extensions Project (7/10)
- Design work on C++ classes
- Reviewed Boost.simd as alternative implementation
- Review of libvpx benchmark
* Misc. (1/10)
- Conference calls
- ARM required online training
== Next week ==
- ARM CodeGen conference in Cambridge
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org
== Progress ==
LLDB development
-- LLDB Call graph analysis for understanding some development nits [1/10]
-- Trying out LLDB server arm and aarch64 cross compilation. [2/10]
-- List down arm-lldb task list with some debugging [2/10]
Miscellaneous [1/10]
-- 96board setup
Holiday [4/10]
-- Monday 16th and Tuesday 17th Feb 2015
== Plan ==
Convert LLDB Arm task list to JIRA cards
Try to fix LLDB server arm and aarch64 cross build issues.
Some GDB patch updates
Connect detox [2/10]
ABE benchmarking automation - TCWG-360 [5/10]
* Backport benchmarking
** Harder than expected, have to build the backport into a binary,
then benchmark that binary, passing information between jobs.
** AFAIK I'm blazing the Jenkins-chainging trail for us.
* Release benchmarking
** New LAVA release broke my image (but quickly fixed by the LAVA folks)
** Now seems to be running into issues with Jenkins/builders/an
anonymous job-slayer
* Misc fixes and improvements
** Main highlight being support for building with separated-out sysroot
Misc - [3/10]
=Plan=
Kick off catomics benchmark runs
(Attempt to) close out cache effects on Juno issue
Carry on with Jenkins
=Issues=
* Some of the Jenkins builders seem unreliable
* My lightly hacked version of the BinaryRelease job is unreliable
** Is the BinaryRelease job itself is reliable
