code review 3822041: runtime: implementation of callback functions for Windo...

runtime: implementation of callback functions for Windows, with split-stack handling

Avoids split-stack overflow from syscall by drawing new g0 split-stack boundaries on OS stack, then calling new scheduler in that space. This allows for further nesting of syscalls from a Go callback.

Important notes:
- builds on CL http://codereview.appspot.com/1696051 (updated to newer tip; included)
- experimental - especially no guarantees on stability when doing panic/recovery in callbacks (no research done)

I'd be more than happy to move the code to the 'exp' directory, but I'm not sure what's the best way to do that in this case, given the tight coupling with local code in proc.c + goc usage.

[czaplinski, 2010-12-21 22:33:36]

Hello rsc, brainman, lxn (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[czaplinski, 2011-01-06 20:16:12]

I'd highly appreciate some feedback on this CL.

If the size of the change is troublesome, I could split it to two parts - one
being an updated version of Alex Brainman's CL (bigger part of the code), and
second containing the further work - but I'd need some guidance, if such a split
is possible at all with current infrastructure.

[brainman, 2011-01-07 06:19:13]

On 2011/01/06 20:16:12, czaplinski wrote:
> I'd highly appreciate some feedback on this CL.
> 

I'm not familiar enough with scheduler and stack splitting code to make a
judgment. Unfortunately, I don't have free time to spend researching it at this
moment. I will get to it eventually, but I don't know when. 

Perhaps, Russ will be able to add something.

Sorry.

Alex

[czaplinski, 2011-01-07 15:08:34]

On 2011/01/07 06:19:13, brainman wrote:
> On 2011/01/06 20:16:12, czaplinski wrote:
> > I'd highly appreciate some feedback on this CL.
> I'm not familiar enough with scheduler and stack splitting code to make a
> judgment. Unfortunately, I don't have free time to spend researching it at
this
> moment. I will get to it eventually, but I don't know when. 

Ok, thanks for the reply.

[brainman, 2011-01-11 04:23:39]

On 2011/01/07 15:08:34, czaplinski wrote:
> ...

I had another go at my CL:

http://codereview.appspot.com/1696051/

and things are working better. Still, I'm not certain what is the right
solution. I didn't look at your code properly yet.

One question:

TEXT runtime·callbackasm(SB),7,$0
+ // We must save 4 registers (to behave as stdcall)
...
+
+ MOVL BX, 12(SP)
+ MOVL BP, 16(SP)
+ MOVL SI, 20(SP)
+ MOVL DI, 24(SP)
+ 

Do you have any references to that fact (that we need to save these registers
during callback)?

Thank you.

Alex

[czaplinski, 2011-01-11 08:36:18]

On 2011/01/11 04:23:39, brainman wrote:
> I had another go at my CL:
> http://codereview.appspot.com/1696051/

Now, unfortunately, it's me who doesn't currently have enough time for reading
interesting code :/

> TEXT runtime·callbackasm(SB),7,$0
> + // We must save 4 registers (to behave as stdcall)
> ...
> +
> + MOVL BX, 12(SP)
> + MOVL BP, 16(SP)
> + MOVL SI, 20(SP)
> + MOVL DI, 24(SP)
> + 
> 
> Do you have any references to that fact (that we need to save these registers
> during callback)?

(For further reference: "Wikipedia says" is to be read as "see:
http://en.wikipedia.org/wiki/Stdcall#stdcall")

If you want to ask:

a) "do we have to behave as stdcall?": for one, Wikipedia says (and others as
well) "stdcall is the standard calling convention in WinAPI calls". But I wasn't
sure if that does also extend to callbacks, so I tested in VS -- cdecl didn't
work, stdcall did.

b) "does stdcall require us to save those registers?": Wikipedia says "Registers
EAX, ECX, and EDX are designated for use within the function", so by compliment
we should assume that the rest of the registers must be preserved by the callee.
I think I've seen that written somewhere more explicitly, but I can't find any
further references by quick Googling now. There's a chance that the Raymond
Chen's series of 5 articles on calling conventions (starting at
http://blogs.msdn.com/b/oldnewthing/archive/2004/01/02/47184.aspx) has that, but
I can't promise now. But see also additional notes below.

c) "does any code called later by callbackasm modify these registers?": I've
read somewhere in Go-related docs (I think somewhere in the sources) that the
Go-suite assumes a "caller saves what he wants" calling convention. I'm not sure
if that actually does affect those 4 registers in compiler-generated code, but
I'm certain that I've seen the hand-written assembly code in Go internals to
destroy some of them. But see also additional notes below.

Additional note: without saving these registers, crashes occur after returning
from callback; with saving, those crashes disappear.

If you'd like me to search further for more detailed references, please say
which one of the three bullets is the most important for you. Sorry if that's
already clear from your question, I'm not a native English speaker so some
subtleties may have eluded me.

[brainman, 2011-01-11 08:44:59]

On 2011/01/11 08:36:18, czaplinski wrote:
> 
> Additional note: without saving these registers, crashes occur after returning
> from callback; with saving, those crashes disappear.
> 
> ...

Do you have a program to demonstrate that? Thank you for all input.

Alex

[czaplinski, 2011-01-11 09:16:54]

On 2011/01/11 08:44:59, brainman wrote:
> On 2011/01/11 08:36:18, czaplinski wrote:
> > Additional note: without saving these registers, crashes occur after
returning
> > from callback; with saving, those crashes disappear.
> 
> Do you have a program to demonstrate that? Thank you for all input.

I did most of my testing on the "drawing.exe" example from Alex Neumann's "Walk"
library, so I expect commenting out the quoted lines in callbackasm() (with
corresponding "restore" lines), rebuilding Go, building Walk ("gomake") and
running drawing.exe (in MSYS, "(cd examples; drawing/drawing.exe)") should show
a nice crash. If your experience shows otherwise, I'd be grateful for info.

greetings
Mateusz

[rsc, 2011-01-19 19:18:10]

setting R=brainman.
assuming will merge this and the other exp/wingui CL