Skip to content

Commit 64de40a

Browse files
committed
[release-branch.go1.3] runtime: revise CL 105140044 (defer nil) to work on Windows
««« CL 105120044 / 824ea5943ba8 runtime: revise CL 105140044 (defer nil) to work on Windows It appears that something about Go on Windows cannot handle the fault cause by a jump to address 0. The way Go represents and calls functions, this never happened at all, until CL 105140044. This CL changes the code added in CL 105140044 to make jump to 0 impossible once again. Fixes #8047. (again, on Windows) TBR=bradfitz R=golang-codereviews, dave CC=adg, golang-codereviews, iant, r https://golang.org/cl/105120044 »»» LGTM=bradfitz R=golang-codereviews, bradfitz, alex.brainman CC=adg, golang-codereviews https://golang.org/cl/108890045
1 parent 69616e4 commit 64de40a

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

src/pkg/runtime/stack.c

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@
99
#include "funcdata.h"
1010
#include "typekind.h"
1111
#include "type.h"
12+
#include "../../cmd/ld/textflag.h"
1213

1314
enum
1415
{
@@ -851,16 +852,24 @@ runtime·newstack(void)
851852
*(int32*)345 = 123; // never return
852853
}
853854

855+
#pragma textflag NOSPLIT
856+
void
857+
runtime·nilfunc(void)
858+
{
859+
*(byte*)0 = 0;
860+
}
861+
854862
// adjust Gobuf as if it executed a call to fn
855863
// and then did an immediate gosave.
856864
void
857865
runtime·gostartcallfn(Gobuf *gobuf, FuncVal *fv)
858866
{
859867
void *fn;
860868

861-
fn = nil;
862869
if(fv != nil)
863870
fn = fv->fn;
871+
else
872+
fn = runtime·nilfunc;
864873
runtime·gostartcall(gobuf, fn, fv);
865874
}
866875

0 commit comments

Comments
 (0)