On Tue, 2015-02-24 at 08:16 +0100, Oliver Kowalke wrote:
2015-02-23 18:44 GMT+01:00 Edward Nevill
: the problem that boost.build does not evaluate os.paltform to ARM the reason is that tools/build/src/engine/jam.h tests for __arm__ which is not set in the case of the 64bit ARM architecture. I'll post a patch.
OK, Thx.
There was also a problem with jump_fcontext in that it was restoring the FP context from x0, not from SP. Interestingly I based my patch on the existing iOS code which also has this bug. I have not fixed it in the iOS code as I have no way of testing anything on iOS.
strange - I got the information that it is working on iOS (I don't own Apple systems).
I think it is broken. It may be that it is just never exercised with the 'save floating point registers' option. Here is what it does #if (defined(__VFP_FP__) && !defined(__SOFTFP__)) ; test if fpu env should be preserved cmp w3, #0 b.eq 1f ; save d8 - d15 stp d8, d9, [x0, #0x00] stp d10, d11, [x0, #0x10] stp d12, d13, [x0, #0x20] stp d14, d15, [x0, #0x30] 1: #endif ; 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] Note that in the case of the integer registers it is saving them to [sp, #XXX] whereas in the case of the fp registers it is to [x0, #XXX]. On entry to jump_context x0 contains a pointer to an fcontext_t (ie a pointer to a single longword which is to receive the new fcontext_t). Writing to [x0, #NNN] is just writing off the end of this into whatever data happens to be there. It may be that this works on iOS because the code is never compiled due to the conditionalisation. All the best, Ed.