[Weekly] 16-20 FEB 2015
== 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.colli...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Problems porting Boost.Context to aarch64 gcc
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 stpd8, d9, [sp, #0x00] stpd10, d11, [sp, #0x10] stpd12, d13, [sp, #0x20] stpd14, 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. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RE: Problems porting Boost.Context to aarch64 gcc
Why don't you just have Boost.Context be a wrapper around getcontext/setcontext/swapcontext and ignore the save_fp argument? Then you don't need to write anything special for AARCH64 or any new target? Thanks, Andrew -Original Message- From: linaro-toolchain-boun...@lists.linaro.org [mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf Of Edward Nevill Sent: Tuesday, February 24, 2015 6:54 AM To: linaro-toolchain@lists.linaro.org Subject: Problems porting Boost.Context to aarch64 gcc 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 stpd8, d9, [sp, #0x00] stpd10, d11, [sp, #0x10] stpd12, d13, [sp, #0x20] stpd14, 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. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Problems porting Boost.Context to aarch64 gcc
Hi Ed, > However, there is a problem with this because gcc may store integer value in > floating point registers around a function call. Are you talking about FP registers being allocated for integer values such that you dont know if FP registers are used in integer application and you have to be conservative and save it? Isn’t this problem may occur in other targets like x86 as well? At least x86 defines TARGET_SPILL_CLASS hooks so that integer registers can be spilled to SSE_REGS instead of memory by the register allocator. Shouldn’t this have the same issue? Thanks, Kugan ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Problems porting Boost.Context to aarch64 gcc
On 24 February 2015 at 23:53, Edward Nevill wrote: > 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? It sounds to me like: (1) any application which doesn't call with save_fp true is broken (2) the API is badly designed and the save_fp argument should be deprecated/removed (3) implementations should ignore save_fp and always save all the registers which the calling convention requires to be saved (4) this is reinventing the getcontext/setcontext wheel, badly... -- PMM ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
