Re: [boost] [context review] Windows ABI requirements

Subject: Re: [boost] [context review] Windows ABI requirements
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-21 19:24:27

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