21 Mar
2011
21 Mar
'11
11:24 p.m.
Am 21.03.2011 23:39, schrieb Holger Grund: > Looking at the fcontext_x86_64_ms_pe_masm.asm it would seem that several ABI > requirements are violated and it is not clear to me why this would always > work. then please tell which of the calling convention I've violated? I believe the code is conform to the x86_64 ABI described in the MSDN. It would be helpful if you could tell me what exactly does not conform to the calling convention? > For instance, the stack is not properly aligned in the call to _exit& > set_fcontext. the stack is allocated with VirtualAlloc() with a multiple of the pagesize (SYSTEM_INFO.dwPageSize). in make_fcontext() I reserve space for return address + 32byte parameter area so that the begining of the stack is on a 16byte border. > At least _exit can call into user code, IIRC (preterminators& > terminator registered via .crt$x* sections) and that code may require a > properly aligned stack. why is it not properly aligned? > I don't see proper unwind descriptors. What happens if an async exception is > triggered in the middle of set_fcontext? The x86 Windows version seems to > have similar problems. IIRC, the dispatch logic checks for EH registration > nodes to be on the stack for x86. fcontext functions store/restore registers no need to install an exception handler. the make_fcontext() registers an EH structure in the stack. If you look inside the test you see that I test throwing and catching exceptions. On x86_64 Windows exception handler is not installed in each stack frame. Unwindhandlers are installed by the compiler - similiar to gcc on UNIX. > What happens if an untrapped exception is trigger in a code path called from > the context entrypoint? it depends - if the function invoked by boost::context doesn't catch exceptions std::terminate() is called other wise the next exceptions handler is triggered. > It would seem that there is an unwind chain via > make_fcontext (which doesn't appear to have any unwind description and would > therefore assumed to be a leaf function). it installes a simple EH in the stack used by the boost::context instance > Is its state necessarily live when set_fcontext is called? ? > What guarantees are there that poking a few fields in the TIB is good enough > to properly switch the context? At least FLS has more than one field in the > TIB. There's also bookkeeping for whether registered callbacks have been > called. I can only follow the things which the MSDN describes - Windows is closed source. For fiber-local-storage the user is responsible to cleanup. > Why is saving the register you save enough? Why wouldn't a future version of > Windows just take down the process if it detects stack hacks. I believe, the > unwinder checks the stack pointer in the unwind context against stack limits > and for 8-byte align at each caller in the chain until a barrier is found. > maybe - I can still use Windows Fiber ABI as boost::context wraps it > How are you certain that kernel32/kernelbase/ntdll don't assume that there's > a guard page (where guard page has the Windows defined meaning as in > PAGE_GUARD) at the end of the stack? Windows 7/XP don't - because you create the stack you could manipulate it > Even if that all works today, how can you be sure it will on Win8, 9 and > beyond? I can't - MS decides how further Windows version will work > To be honest, I don't think a library outside the operating system is not > the proper place to do this kind of thing at all (and even if you're part of > the OS it's an incredibly hard thing to get right -- UMS had tons of > problems in Win7 RTM) > then use boost::context together with Windows Fiber ABI > BTW, glancing over the docs, an implicit conversion from size_t to > protected_stack seems weird, but that might just be a glitch in the doc > build. could you tell where did you found it