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
* TSAN support for Aarch64 (5/10)
Fixed some kernel size issues in my local working tree. (TCWG-581) .
GCC does not default to -fPIE or -pie. Ran into address layout
issues when I used -fsanitize=thread. Some test cases passed with the
mapping I used for 42 bit VA when -pie and -fPIE are added.
* Bug 869 - Looking at match.pd to remove type promotion in ABS_EXPR (1/10)
* Emails, meetings. (2/10)
* Linaro 1-1 with maxim and Ryan.
* AMD meetings/event, 1-1 with AMD manager, status meeting.
* GCC mailing list.
Leave on 20-Feb-2015 (2/10)
== Plan ==
* TSAN support for Aarch64 work fixing GCC -fsanitize=thread option.
* Break tasks under TCWG-581.
* LLVM build with local patches.
* Bug869.
* Misc and Meetings (AMD, LInaro)
== Progress ==
* compiler-pass to widen computation (TCWG-547) - (5/10)
- Analysed core-mark code size regression
- fixed constant handling
- Added VRP support for ZEXT_EXPR
* Improve register allocation for AArch64 (TCWG-620) - (1/10)
- Looked at the relevant patches
* Misc (4/10)
- Setting up ABE benchmarking scripts
- Ran into some LAVA related issues for ABE benchmarking
- Recovering from connect
- Started with 69 board setup
== Plan ==
* TCWG-620 and TCWG-547
* ABE benchmarking
== Progress ==
* GCC trunk/4.9 monitoring
* Neon intrinsics tests
- committed the last patch of the 2nd series.
- about another 1/3 of the tests remain to be converted: will wait
for GCC stage1
* AArch64 sanitizers (2/10)
- Renato committed my patches to enable ASAN in LLVM/AArch64
- the official aarch64 buildbot (Juno) had problems after these, so
the asan tests are disabled again until the problem is understood.
Probable board configuration problem, since the tests passed on our
Juno.
- preparing a patch to solve the long standing issue with dependency
on aarch64 kernel version (kernel_old_[ug]id)
* Backports (4/10)
- reviews
- respawned validations under MergeFarm
* ABE:
- improving reporting
* Misc (4/10)
- meetings, conf-calls, emails, ....
== Next ==
Connect, then holidays
== Progress ==
* Rebooting brain after Connect (2/10)
* Friday off (2/10)
* Release 3.6 (CARD-1431 1/10)
- Spinning RC3, RC4
- Long discussions about Phoronix benchmark regressions
* Buildbots (CARD-1823 2/10)
- Buildbot cleanup and reshape
- Adding two new internal buildbots
- Investigating AArch64 broken bot
* Background (3/10)
- Code review, meetings, discussions, etc.
- Sprint planning
- Catching up on emails
- Servers purchase
- EuroLLVM paper reviews
== Plan ==
* Install new servers when they come
* Add the two new bots upstream
* Plan LLDB with Omair, contact Google
* Plan TSAN with Venkat
* Help Christophe investigate ASAN on AArch64
Holiday [3/10]
ABE benchmarking automation - TCWG-360 [3/10]
* Initial Jenkins implementation
Investigating cache effects on Juno - LDTS-1238 [2/10]
* One effect due to write streaming, others still to look at
Misc [2/10]
* Unpacking, some background catomics
Connect [10/10]
=Plan=
Carry on with Jenkins implementation
Run some benchmarks on catomics
Juno cache effects
Write up/think about where to go with libm exercising
