core: support for Go 1.15

[deadprogram]

This PR makes the needed changes so that TinyGo will work with the new Go 1.15 release. It also adds Go 1.15 to the tests that are run by CircleCI and MS Azure.

[deadprogram]

https://dev.azure.com/tinygo/tinygo/_build/results?buildId=1964&view=logs&j=572904f9-79b1-51c4-99c0-531b4ffd4297&t=a5f187cc-e880-5285-3ea6-8c475049272d

C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large: 90506
collect2.exe: error: ld returned 1 exit status

FAIL	github.com/tinygo-org/tinygo [build failed]

Looks like we hit the limit on number of exported symbols in Windows? http://lists.llvm.org/pipermail/llvm-dev/2019-June/133204.html

[aykevl]

I googled a bit but am not sure what is causing the link error here. Note that 90506 is significantly larger than the maximum of 65535 so something changed probably, probably in Go 1.15.

[aykevl]

Actually I'm surprised how few changes are needed to get this working. Often the diff is much larger.

[aykevl]

Somehow people online talk about this issue as if it's an issue with DLLs, but we're not building a DLL right?

[deadprogram]

I think the DLL comments are still referring to the number of exported functions.

In our case, might they be debug functions being exported?

[aykevl]

That's possible, at least some people on the Internet say they fixed the issue by disabling debug symbols. However, I think that would be debug symbols in Go as LLVM didn't change. Maybe there's something in the release notes (I didn't check).

[deadprogram]

ld issue: encountering ld: error: export ordinal too large needs the compilation flag -O1

according to https://ginkgo-project.github.io/ginkgo/doc/develop/install_ginkgo.html

[deadprogram]

I'm not exactly sure where to try putting that flag so it gets included in the Windows build, however.

[aykevl]

That doesn't make much sense to me. -O1 means with light optimizations enabled. We are already building LLVM with full optimizations enabled, I doubt reducing optimizations is going to help (it will just make TinyGo slower on Windows). Additionally, LLVM didn't change, what changed was Go (so it shouldn't be an issue with how LLVM was built).

[deadprogram]

Looks like it is not just us: golang/go#40795

[aykevl]

Great, maybe we should wait until that issue is resolved.

From the release notes:

Go now generates Windows ASLR executables when -buildmode=pie cmd/link flag is provided. Go command uses -buildmode=pie by default on Windows.

This might be it. I don't know how ASLR works on Windows but on Linux it works by building the exectuable as a shared object. If the same is true for Windows, disabling PIE might work around the issue.

[deadprogram]

I was just reading that. Looks like we need -buildmode=exe where should that be put, LDFLAGS?

[deadprogram]

setting the buildmode (-buildmode=exe) when running "go run" or "go build" resolves the issue.

according to https://groups.google.com/g/golang-nuts/c/kLgEb2kxI6A/m/jVArMVO5BQAJ

[aykevl]

Probably in these places:
https://github.com/tinygo-org/tinygo/blob/release/Makefile#L182
https://github.com/tinygo-org/tinygo/blob/release/Makefile#L185

For example, replacing $(GO) test -v with $(GO) test -v -buildmode=exe.

[aykevl]

setting the buildmode (-buildmode=exe) when running "go run" or "go build" resolves the issue.

according to https://groups.google.com/g/golang-nuts/c/kLgEb2kxI6A/m/jVArMVO5BQAJ

That's for a different issue (unrecognized option --high-entropy-va).

[deadprogram]

OK that did it. All tests passing now on all architectures! I think ready to merge.

[aykevl]

Looks good to me.

[deadprogram]

Thanks everyone for the feedback, and special thanks to @QuLogic who got this process started.

Now merging.