Golang on windows/arm

[Sebastian Schuler]

Okay, so this might be an weird post, but I'm trying to wrap my head around the problems with porting the golang runtime to other systems and I'm only a dumb noob. My searches through the various aspects about the runtime are (and please correct me if I'm wrong):

- Small specific runtime code mainly written in C and some parts in assembler.

- Wrappers around OS calls which access the kernel(s) directly.

-> To port the runtime to a different OS running on an proven to work architecture like eg. linux/amd64 to freebsd/amd64 you need to implement the needed OS calls and it should be working!?

The catch about other architectures is that the linker needs to support it (for windows -> PE executeables) *and* it needs to support segmented stacks? As far as I understood mingw(-64) for windows does not support windows/arm. 

So I'm thinking about LLVM. Well yeah it might not be as fast as the default go compiler but, meh... whatever works... Wouldn't it be possible to use a LLVM frontend for go and use the LLVM byte code with an ARM backend and a native linker like the one in Visual Studio (does it support segmented stacks?) or at least with the LLVM interpreter?

Is anybody working on something similar or on other ports for windows/arm?

Please enlighten me, thanks!

[Daniel Theophanes]

 I don't think anyone is currently working on a Windows-arm port. We have a Windows-x86 port, and a Linux-arm port though. Due to how applications are distributed on Windows RT, I don't think this is going to happen any time soon.

If you wanted to try, don't do anything with LLVM, just port the normal go tool chain. You would need to modify windows assembly bits, and probably make a few tweaks, but probably not too much more then that.

Per other discussions on this list. If you want this to happen, make it happen out of the tree, have all tests pass.

[brainman]

> ... Is anybody working on something similar or on other ports for windows/arm?

I don't have windows/arm and I have never investigated how it works, so my advise could be completely wrong, but ...

All Go tools can be used to target any foreign host (excluding cgo). It means you should be able to use all Go tools on windows/386 or windows/amd64 to build for new windows/arm. If I would be doing the port, I would start with that, so I don't need to port any tools at the start.

Then you problem is simplified to:

1) change Go linker (8l/6l) to support whatever executable output format that windows/arm requires (both windows/386 and windows/amd64 support PE, I don't know about arm);

2) implement all arch specific code in all packages (runtime would be most complicated, but you should start with that, because nothing will work without runtime package).

You should be able to build this (once runtime package is converted - even not completely):

package main

func main() {

println("Hello")

}

on windows/386 (or any other supported Go platform) and copy executable to windows/arm and run it there and see it output "Hello".

Alex

[Sebastian Schuler]

As far as I know Windows RT uses the same PE format as Windows x86/amd64:

- http://en.wikipedia.org/wiki/Protable_Executable_Format  

- http://forum.xda-developers.com/showthread.php?t=2096820

- http://www.exploit-monday.com/2013/07/WinRT-ARM-Shellcode.html

but needs some minor changes (?). Unfortunately 5l doesn't support windows  (http://golang.org/cmd/ld/), but I don't know what the problem is/was.

Plus the runtime shouldn't need any changes at all, the available libraries are mainly the same and Windows RT shares the kernel with Windows 8. It should be easily possible to port the runtime, see a list of ported application here: http://forum.xda-developers.com/showthread.php?t=2092348

I have no a chance to provide changes to the linker, since I understand way way to little from those things and have barely the time to work me into it. But what about using the linker provided by Visual Studio? Why reinvent something what is already there?

[Daniel Theophanes]

Go is cross-platform.

Visual Studio is not. At all. I routinely cross compile windows programs from a Linux box.

If you are not able to do this work at this point your interest is noted.

[james4k]

This would face similar constraints to darwin/arm (iOS) and probably nacl, so it makes sense to keep windows/arm in mind at the same time those are being considered.

[brainman]

On Monday, 18 November 2013 21:34:44 UTC+11, Sebastian Schuler wrote:

> ... Unfortunately 5l doesn't support windows (http://golang.org/cmd/ld/), but I don't know what the problem is/was.

Yes we've never added any windows related code to 5l. No one complained about it - I guess there aren't many people building windows programs on arm. We can copy the code, if someone really need it.

> ... Plus the runtime shouldn't need any changes at all, the available libraries are mainly the same and Windows RT shares the kernel with Windows 8. It should be easily possible to port the runtime, ...

If you say so. I don't know.

> ... I have no a chance to provide changes to the linker, since I understand way way to little from those things ...

Yes, it is a problem. But there are many knowledgeable people here willing to help.

> ... and have barely the time to work me into it. 

That is a bigger problem.

> ... But what about using the linker provided by Visual Studio? Why reinvent something what is already there?

I don't think that using VS linker would be any easier. I can probably come up with many reasons. Here some:

- It does not have functionality we require;

- It does not come with source code so we can change it;

- ...

Alex

[minux]

On Nov 18, 2013 5:34 AM, "Sebastian Schuler" <mail.sebast...@gmail.com> wrote:
> but needs some minor changes (?). Unfortunately 5l doesn't support windows  (http://golang.org/cmd/ld/), but I don't know what the problem is/was.

i don't expect much changes to cmd/5l, as most of the pe code is portable and in cnd/ld.

> Plus the runtime shouldn't need any changes at all, the available libraries are mainly the same and Windows RT

this is incorrect. the two major parts of work to port Go to another platform are linker and runtime/syscall work.

> shares the kernel with Windows 8. It should be easily possible to port the runtime, see a list of ported application here: http://forum.xda-developers.com/showthread.php?t=2092348
>
> I have no a chance to provide changes to the linker, since I understand way way to little from those things and have barely the time to work me into it. But what about using the linker provided by Visual Studio? Why reinvent something what is already there?

because we don't want to rely on closed source components, and besides, not everybody wants VS just for Go (similarly, some people don't want to install mingw, but that is not required for binary distribution users).

[Aram Hăvărneanu]

Forgetting for a moment that the Visual Studio linker is totally

unsuitable, it doesn't run on Unix and even if it did, we couldn't

distribute it. We need to be able to cross compile.

You are vastly underestimating the effort required to bringup the

Windows/ARM port. It's a reasonable job, it's not unfathomable, but you

are vastly underestimating it.

[Sebastian Schuler]

Okay sorry for bringing up the VS linker, please forget about it, I never mentioned it :D 

windows/arm is more than what probably most people think about it, there is Windows RT and Windows CE (a little bit Windows Mobile but let's forget about that one). Windows CE is used quite often in embedded devices and has a significant/relevant market share so having a linker for windows{rt/ce}/{arm,386} would be really nice!

I've done a comparison about the currently used syscalls of the windows/386 port and the available ones in Windows CE (>= 5.0). You can find it here: https://docs.google.com/spreadsheet/ccc?key=0AnfAL9wNxT7XdHFBZUx5Y1hmOXdnVk5VdmwweEJMZ2c&usp=sharing There are a bunch of APIs missing, it would be great if someone who has the experience could comment on the critical parts!? As I said Windows RT should be much closer to Windows 8, unfortunately there are deployment difficulties and not many devices out in the wild.

[minux]

On Nov 19, 2013 8:17 AM, "Sebastian Schuler" <mail.sebast...@gmail.com> wrote:
> windows/arm is more than what probably most people think about it, there is Windows RT and Windows CE (a little bit Windows Mobile but let's forget about that one). Windows CE is used quite often in embedded devices and has a significant/relevant market share so having a linker for windows{rt/ce}/{arm,386} would be really nice!

i think if we support windows/arm at all, we should target windows rt or 8 only.

> I've done a comparison about the currently used syscalls of the windows/386 port and the available ones in Windows CE (>= 5.0). You can find it here: https://docs.google.com/spreadsheet/ccc?key=0AnfAL9wNxT7XdHFBZUx5Y1hmOXdnVk5VdmwweEJMZ2c&usp=sharing There are a bunch of APIs missing, it would be great if someone who has the experience could comment on the critical parts!? As I said Windows RT should be much closer to Windows 8, unfortunately there are deployment difficulties and not many devices out in the wild.

the deployment problem feels like that of iOS port. If we cannot setup builder for windows/arm, the port won't be accepted.

some of the missing apis are very crucial so i think we can't have a fully function port to ce.

[Sebastian Schuler]

Okay I've (partially) ported the runtime to windowsce/386!

The basic runtime (scheduler, output, panic...) is running, some (most?) packages should work too. Honestly I don't know what exactly works since I'm not able to run any tests since I have not ported dist, compiler, linker... but I'm cross compiling for windows/386 which currently gives me a valid executable for Windows CE 2013. 

You can find the code which bases on upstream somewhere shortly after 1.2rc5: https://github.com/sebastianschuler/go

Please see the document here for a more detailed look into the differences between regular windows and windowsce: https://docs.google.com/spreadsheet/ccc?key=0AnfAL9wNxT7XdHFBZUx5Y1hmOXdnVk5VdmwweEJMZ2c&usp=sharing

Please try out yourself and hopefully some of you like to contribute!

[Aram Hăvărneanu]

go test -c will produce a test binary. You can cross-compile this test binary and move it over.

[brainman]

On Sunday, 24 November 2013 05:39:01 UTC+11, Sebastian Schuler wrote:

> Okay I've (partially) ported the runtime to windowsce/386!

Excellent!

> ... I don't know what exactly works since I'm not able to run any tests ...

You can build tests, just like Aram suggested, copy the binary to your target pc and run it there. You can also build some Go programs (maybe gofmt or godoc) and run them there.

> ... since I have not ported dist, compiler, linker...

You only need these, if you are planing to do development on your target pc. We use mingw gcc to build them. If mingw is available, you should be able to build these.

> ... but I'm cross compiling for windows/386 which currently gives me a valid executable for Windows CE 2013.

Sounds good.

> You can find the code which bases on upstream somewhere shortly after 1.2rc5: 

> https://github.com/sebastianschuler/go

Runtime changes aren't large. It uses same binary pe format. Some Windows APIs are missing, but you can build some programs with what you have. It depends on what you need.

Good job.

Alex

[Sebastian Schuler]

Okay I've run a couple of test but was facing issues with the hdd space on my virtual machine so I couldn't run all tests. Testing with cross compiled binaries is also a little cumbersome, since these are big binaries, sometime try to get external files etc... so having the complete tools working on windowsce would make testing much easier.

Nevertheless many of the failed tests failed since they were trying to access pipes to redirect stdio, stdout and stderr which isn't supported on windowsce. So I tried to fix this first but I'm unsure how to do so. Possible replacements for pipes would be message queue, memory mapped files or sockets. The last two would possibly have some security issues. Does someone have suggestion for this problem? Is it currently possible to transmit the pipe handles to the child process during a fork, or is this a basic requirement?

[brainman]

On Tuesday, 26 November 2013 07:57:31 UTC+11, Sebastian Schuler wrote:

> ... facing issues with the hdd space on my virtual machine so I couldn't run all tests. ...

Strange. Generally standard package tests do not use much disk space. I would be more concerned about your memory usage.

> ... Testing with cross compiled binaries is also a little cumbersome, since these are big binaries, sometime try to get external files etc... so having the complete tools working on windowsce would make testing much easier.

Sure. Some test expects all tools to be there. You can try and get everything built from source, I guess. Is there mingw available for that platform? If it is, you should be able to proceed with small adjustments in src/cmd/*. Looks like you are using 386 cpu, so all windows/386 code should work - you will need to add your new GOOS handling, but just grep for "windows" and do the same for your new GOOS. Same with src/cmd/dist. I am not sure how powerful your computer is - perhaps it will be too much for it.

> ... Nevertheless many of the failed tests failed since they were trying to access pipes to redirect stdio, stdout and stderr which isn't supported on windowsce.

Yes. "go" cmd executes external commands a lot (platform independent code is in os/exec.Command). Given what I see about Windows CE CreateProcess implementation, it does not look promising. No CreatePipe, no new "current directory", no new environment, no psiStartInfo support (how are you going to redirect new process stdin/stdout/stderr). You can look at the code in os/exec.Command and try and rewrite it with what APIs you have. You might end up with some missing features. But it means, you won't be able to build "go" command. So you back to cross-compiling on another computer. But, depending on what your goal is, it could be enough.

> ... So I tried to fix this first but I'm unsure how to do so. Possible replacements for pipes would be message queue, memory mapped files or sockets. The last two would possibly have some security issues. Does someone have suggestion for this problem?

I don't see how you can redirect stdin/stdout/stderr with CreateProcess on Windows CE. If not that, then you can communicate with the child in any way you like - whatever your new process supports.

> ... Is it currently possible to transmit the pipe handles to the child process during a fork, or is this a basic requirement?

It looks to me that fInheritHandles parameter of CreateProcess is not supported too. Perhaps, you can use some form of communication and inter-process version of DuplicateHandle.

Alex

[Sebastian Schuler]

Am Dienstag, 26. November 2013 04:58:35 UTC+1 schrieb brainman:

On Tuesday, 26 November 2013 07:57:31 UTC+11, Sebastian Schuler wrote:

> ... facing issues with the hdd space on my virtual machine so I couldn't run all tests. ...

Strange. Generally standard package tests do not use much disk space. I would be more concerned about your memory usage.

Thanks for your feedback! Disk space is somehow limited since I simple couldn't manage it to expand the preconfigured disk for my VM. On the other side RAM is no problem since I'm running an VM :D Well this get's sorted out at some time...

 

> ... Testing with cross compiled binaries is also a little cumbersome, since these are big binaries, sometime try to get external files etc... so having the complete tools working on windowsce would make testing much easier.

Sure. Some test expects all tools to be there. You can try and get everything built from source, I guess. Is there mingw available for that platform? If it is, you should be able to proceed with small adjustments in src/cmd/*. Looks like you are using 386 cpu, so all windows/386 code should work - you will need to add your new GOOS handling, but just grep for "windows" and do the same for your new GOOS. Same with src/cmd/dist. I am not sure how powerful your computer is - perhaps it will be too much for it.

> ... Nevertheless many of the failed tests failed since they were trying to access pipes to redirect stdio, stdout and stderr which isn't supported on windowsce.

Yes. "go" cmd executes external commands a lot (platform independent code is in os/exec.Command). Given what I see about Windows CE CreateProcess implementation, it does not look promising. No CreatePipe, no new "current directory", no new environment, no psiStartInfo support (how are you going to redirect new process stdin/stdout/stderr). You can look at the code in os/exec.Command and try and rewrite it with what APIs you have. You might end up with some missing features. But it means, you won't be able to build "go" command. So you back to cross-compiling on another computer. But, depending on what your goal is, it could be enough.

This seems to be the biggest problem right now, CreateProcess on WinCE is somewhat crippled, "current directory", new environment and inherited handles are still a problem but I found a nice solution for the CreatePipe and psiStartInfo problems. The cegcc port has a library called "PipeLib" which creates a pipe device driver (a dll in the Windows directory) which then can be used for pipes and redirection of stdin, stdout and stdout. You can find it here: http://sourceforge.net/p/cegcc/code/HEAD/tree/trunk/cegcc/tools/PipeLib/ 

> ... So I tried to fix this first but I'm unsure how to do so. Possible replacements for pipes would be message queue, memory mapped files or sockets. The last two would possibly have some security issues. Does someone have suggestion for this problem?

I don't see how you can redirect stdin/stdout/stderr with CreateProcess on Windows CE. If not that, then you can communicate with the child in any way you like - whatever your new process supports.

> ... Is it currently possible to transmit the pipe handles to the child process during a fork, or is this a basic requirement?

It looks to me that fInheritHandles parameter of CreateProcess is not supported too. Perhaps, you can use some form of communication and inter-process version of DuplicateHandle.

Alex

Would using such a "device driver" make the port not comply with any restrictions for an official port? I would really like to have windowsce/{arm,386} getting upstream!

[Sebastian Schuler]

Forgot to post an example how to use this driver for stdin, stderr, stdout redirect:

/* showing only stdout for simplicity sake. */

HANDLE rd, wr;

WCHAR pipe_name[MAX_PATH];

WCHAR old_stdout_path[MAX_PATH];

/* create it - CreatePipe returns BOOL. */

CreatePipe (&rd, &wr, NULL, 0);

GetStdioPathW (1, old_stdout_path, &len);

/* get internal pipe name - this is really the device's name, like

PD00: */

GetPipeName (rd, pipe_name);

/* set it in the parent so the child inherits it */

SetStdioPathW (1, pipe_name);

CreateProcess (...);

/* restore */

SetStdioPathW (1, old_stdout_path);

while (1)

{

DWORD read;

/* read from the read end of the pipe */

/* block waiting for input */

if (!ReadFile (rd, ..., &read))

return;

if (read)

{

/* do whatever with the data. */

}

}

[brainman]

On Wednesday, 27 November 2013 19:31:25 UTC+11, Sebastian Schuler wrote:

> ... Would using such a "device driver" make the port not comply with any restrictions for an official port? I would really like to have windowsce/{arm,386} getting upstream!

I wouldn't see a "device driver" as a show stopper. Besides you wouldn't need to use it unless you call CreateProcess (and a lot of programs don't).

But to make your port official is a different fish altogether. Here is a recent discussion about removing some existing platforms: https://groups.google.com/d/topic/golang-dev/QW4zUbMHMBM/discussion. You should read it to understand what is required. Especially this https://code.google.com/p/go-wiki/wiki/PortingPolicy doco by rsc.

Alex

[Sebastian Schuler]

Am Donnerstag, 28. November 2013 05:38:28 UTC+1 schrieb brainman:

On Wednesday, 27 November 2013 19:31:25 UTC+11, Sebastian Schuler wrote:

> ... Would using such a "device driver" make the port not comply with any restrictions for an official port? I would really like to have windowsce/{arm,386} getting upstream!

 

I wouldn't see a "device driver" as a show stopper. Besides you wouldn't need to use it unless you call CreateProcess (and a lot of programs don't).

Well that's great, since the library is working almost without any problems now (will push the commits soon)! 

 

But to make your port official is a different fish altogether. Here is a recent discussion about removing some existing platforms: https://groups.google.com/d/topic/golang-dev/QW4zUbMHMBM/discussion. You should read it to understand what is required. Especially this https://code.google.com/p/go-wiki/wiki/PortingPolicy doco by rsc.

Alex

 I understand the requirements. Nevertheless the first part is to have a working set of the runtime and tools. Pipes are working now and I got around the space restrictions so I was able to perform all tests "inclusive" the needed testdata. Well since current directory and in general the path specific things aren't working probably the testdata couldn't be found anyway :-/ Here's the hard reality: 

output.log

and

error.log

[brainman]

On Monday, 2 December 2013 03:59:20 UTC+11, Sebastian Schuler wrote:

> ... since current directory and in general the path specific things aren't working probably the testdata couldn't be found anyway :-/ Here's the hard reality: ...

That is a lot of errors. You can disable some tests for your platform. But it is too many, as it stands now. I don't know what these problems are - perhaps it is something that is easy enough to fix, perhaps they are show stoppers. You have to understand what they are and decide what to do about it. It looks like your Go tools are mostly working, so you should be able to debug your problems.

Alex

[Sebastian Schuler]

Am Dienstag, 3. Dezember 2013 04:32:00 UTC+1 schrieb brainman:

That is a lot of errors. You can disable some tests for your platform. But it is too many, as it stands now. I don't know what these problems are - perhaps it is something that is easy enough to fix, perhaps they are show stoppers. You have to understand what they are and decide what to do about it. It looks like your Go tools are mostly working, so you should be able to debug your problems.

Much better now with working path:

output.log 

error.log

The biggest part which is not working is network I/O since WinCE doesn't have io completion ports. Is there a chance to get it working with the generic select without a complete rewrite of the network part?

[Dave Cheney]

Does WinCE support POSIX select(2) ? If so, the solaris port will be
landing a version of netpoll_select.c which we ported from gccgo,
which might be of use.

[brainman]

On Wednesday, 4 December 2013 05:26:39 UTC+11, Sebastian Schuler wrote:

> Much better now with working path:

Excellent. I would have given up myself by now :-)

> ... The biggest part which is not working is network I/O since WinCE doesn't have io completion ports. Is there a chance to get it working with the generic select without a complete rewrite of the network part?

I looked back in history https://codereview.appspot.com/1600041, and, it seems, we never had anything but "completion ports" version. So that is no go for you.

Perhaps you should go with Dave's suggestion. Look at new Solaris port https://groups.google.com/d/topic/golang-dev/rK6JcsWbJ6s/discussion. You should look at netpoll_select.c file in https://codereview.appspot.com/35990043 CL. Perhaps you could use some of that code. You might also use existing code from netpoll_windows.c for syscall access.

Alex

[Sebastian Schuler]

On Wednesday, 4 December 2013 05:26:39 UTC+11, Sebastian Schuler wrote:

> Much better now with working path:

Excellent. I would have given up myself by now :-)

Thanks, but honestly it wasn't that much work, you did the heavy stuff with the windows port and I've just been changing some things here and there.

 

> ... The biggest part which is not working is network I/O since WinCE doesn't have io completion ports. Is there a chance to get it working with the generic select without a complete rewrite of the network part?

I looked back in history https://codereview.appspot.com/1600041, and, it seems, we never had anything but "completion ports" version. So that is no go for you.

Perhaps you should go with Dave's suggestion. Look at new Solaris port https://groups.google.com/d/topic/golang-dev/rK6JcsWbJ6s/discussion. You should look at netpoll_select.c file in https://codereview.appspot.com/35990043 CL. Perhaps you could use some of that code. You might also use existing code from netpoll_windows.c for syscall access.

Alex

Windows CE does indeed support select(2) so the solaris code could be used. But I see a lot of stuff which won't be working in net/fd_windows.go. It seems like there is some work to do. Unfortunately I can't work on the port  for the next 2-3 weeks since I need to finish my master thesis but if anyone wants to help his work will be greatly appreciated!

What needs work right now:

- net (!)

- tools (!)

- various problems with relative path vs. abs path in WinCE

- environment variables

- own implementation of argv

- console ctrl handler

- various quirks and hacks all around

- cpu profiling

the repository can be found here: https://github.com/sebastianschuler/go

Informations about windows API calls: apicalls

[brainman]

On Wednesday, 4 December 2013 21:05:12 UTC+11, Sebastian Schuler wrote:

> ... you did the heavy stuff with the windows port ...

There were many people who did that.

 

> ... It seems like there is some work to do. 

Yes.

> ... Unfortunately I can't work on the port  for the next 2-3 weeks since I need to finish my master thesis but if anyone wants to help his work will be greatly appreciated!

Perhaps others. It would be fun, but I don't have any spare time right now. I also don't have any Windows CE computers - never even seen one.

Alex

[Sebastian Schuler]

(Hopefully) fixed absolute path problems.

Added own version of CommandLineToArgv.

What's missing:

- net (!)

- tools (!)

- environment variables

- console ctrl handler

- various quirks and hacks all around

- cpu profiling

[brainman]

On Sunday, 8 December 2013 01:58:46 UTC+11, Sebastian Schuler wrote:

> What's missing:

> - net (!)

You can also try to implement net without any special "use single os thread for many net connection" treatment. Just use connect/read/write/close (whatever they are) Windows API. This is not acceptable for large servers with many connections, but, I guess, you are not targeting these. You might have to drop some features, like deadlines and maybe others, but that is a price to pay. Even current net windows version does not implement everything that linux does, no unix sockets, ...

- tools (!)

What do you mean by "tools"?

- environment variables

That is important for "go" tool and compilers.

Alex

[Sebastian Schuler]

Am Dienstag, 10. Dezember 2013 07:42:11 UTC+1 schrieb brainman:

On Sunday, 8 December 2013 01:58:46 UTC+11, Sebastian Schuler wrote:

> What's missing:

> - net (!)

You can also try to implement net without any special "use single os thread for many net connection" treatment. Just use connect/read/write/close (whatever they are) Windows API. This is not acceptable for large servers with many connections, but, I guess, you are not targeting these. You might have to drop some features, like deadlines and maybe others, but that is a price to pay. Even current net windows version does not implement everything that linux does, no unix sockets, ...

That's probably the way to go since io completion ports are not available, there's no way to create those large servers with many connections. But that's never the use case for those small devices anyway.

 

- tools (!)

What do you mean by "tools"?

The stuff in /cmd like dist...

  

- environment variables

That is important for "go" tool and compilers.

Jup, environment variables are possible with a hack over the registry but per process ones are more difficult. Do the tools and compilers use CreateProcess with new environment heavily? Since that would pose a problem...

[brainman]

On Tuesday, 10 December 2013 17:55:41 UTC+11, Sebastian Schuler wrote:

> ... That's probably the way to go since io completion ports are not available, ...

I wouldn't write off runtime/netpoll based solution completely (perhaps you can use select Windows API or similar, as you suggested before). This way you will get a lot of functionality for free.

>>> - tools (!)

>> 

>> What do you mean by "tools"?

> 

> The stuff in /cmd like dist...

If you don't use cmd/dist, how do you build on your device? Do you have mingw or similar on the device?

>>> - environment variables

>> 

>> That is important for "go" tool and compilers.

> 

> Jup, environment variables are possible with a hack over the registry but per process ones are more difficult. Do the tools and compilers use CreateProcess with new environment heavily? Since that would pose a problem...

Go tools do use CreateProcess with new environment a lot. Many external tools use these too: http://build.golang.org/, $GOROOT/misc/dist/bindist/go.

Alex

[brainman]

Like I said at the start, perhaps you can cross-compile on another OS. But if you want your port to be part of Go repo, then you would need to support all these things.

Alex

[Elias Naur]

On Wednesday, December 11, 2013 2:56:41 AM UTC+1, brainman wrote:

Like I said at the start, perhaps you can cross-compile on another OS. But if you want your port to be part of Go repo, then you would need to support all these things.

Alex

FWIW, there is potential ports that will require cross compilation from a more capable host. Darwin/arm and android/arm comes to mind. See also issue 4714, slated for Go 1.3.

 - elias

[edse...@gmail.com]

Sebastian,

It looks like you made a lot of progress in a short period of time, but then the updates stopped. Did you get any further? I ask because a potential need has come up for a WinCE6.0 port of Golang, and this thread is the closest I've found to something that sounds like it could fit. 

On Saturday, November 16, 2013 at 8:41:10 AM UTC-5, Sebastian Schuler wrote:

Okay, so this might be an weird post, but I'm trying to wrap my head around the problems with porting the golang runtime to other systems and I'm only a dumb noob. My searches through the various aspects about the runtime are (and please correct me if I'm wrong):

- Small specific runtime code mainly written in C and some parts in assembler.

- Wrappers around OS calls which access the kernel(s) directly.

-> To port the runtime to a different OS running on an proven to work architecture like eg. linux/amd64 to freebsd/amd64 you need to implement the needed OS calls and it should be working!?

The catch about other architectures is that the linker needs to support it (for windows -> PE executeables) *and* it needs to support segmented stacks? As far as I understood mingw(-64) for windows does not support windows/arm. 

So I'm thinking about LLVM. Well yeah it might not be as fast as the default go compiler but, meh... whatever works... Wouldn't it be possible to use a LLVM frontend for go and use the LLVM byte code with an ARM backend and a native linker like the one in Visual Studio (does it support segmented stacks?) or at least with the LLVM interpreter?

Is anybody working on something similar or on other ports for windows/arm?

Please enlighten me, thanks!