On Monday 19 Mar 2012 16:04:26 Sascha Peilicke wrote:
Re: [opensuse-factory] gcc47, Go language, gold linker From: Sascha Peilicke
To: opensuse-factory@opensuse.org Date: Monday 16:04:26 Spam Status: Spamassassin Not enough information to check signature validity. Show Details On 03/19/2012 11:16 AM, Richard Guenther wrote:
On Sat, 17 Mar 2012, Graham Anderson wrote:
Sascha, list,
With Go language changes pretty much finished and a Go 1.0 stable release iminent I'd like to progress more with how we support this language. We already have a very good Go compiler in Factory but I would also like to have the gccgo compiler available for 12.2 so that we can offer a great Go hacking environment.
Go currently has two reference implementations of it's spec, the first is the more commonly used {5,6,8}g compiler which is developed with the main Go tree, it's a derivative of Ken Thompson's plan 9 C compiler. The second reference implementation is the gccgo frontend introduced with gcc46 by Ian Taylor (who engineered the gold linker).
The benefits of having both compilers are as follows: 5g, 6g, 8g compilers are very fast
but
gccgo compiler generates faster code
also
The language is new, having two reference compilers is great for sanity checks on Go code projects.
Some developers may be more comfortable with a gcc frontend because they use the gcc collection anyway.
Building the gccgo frontend is no problem, however to implement the same parity of concurrency features as the other compiler, gccgo needs to be built with the gold linker.
Go concurrency is based on lightweight threads called goroutines, the goroutines are multiplexed on top of OS threads with each goroutine having their own small initial stack. This is managed by the Go runtime but the compiler and linker must support it.
The version of the gold linker in factory (binutils 2.22) supports segmented stacks however gcc47 is currently built with traditional ld linker.
Since now is the time where we are potentially adopting gcc47 it's also a good time to ask about what I would like to see from it. I can easily build gcc47 on my local OBS with my preference for the gold linker, but it's clear from the .spec.in comments of the gcc package that the compiler testing framework is an internal affair. I would therefore request that an analysis of building gcc with the gold linker was performed on the internal test framework for gcc.
If it's impractical to ask for a change of linker at the same time as a change of gcc version, then by all means say so (note that I'm only asking that gcc be built with gold linker). In which case I can try and maintain a gccgo compiler inside the go language project.
The much bigger issue is that the two Go compilers are not ABI compatible. So IMHO for openSUSE we have to choose one (though I understand in Go you are supposed to always re-compile the libraries you use with your program).
Right, currently it wouldn't be a big issue, as there is not (yet) a shared library concept available in Go. Nonetheless, I think this was also the reason why it wasn't done with the release of GCC-4.6 (back then it was me asking
gccgo has *some* support for dynamic linking but I'm really not very well versed in how it works or how it's supported. However, I was wondering this afternoon if I'm perhaps too eager to push having two implementations of Go via two differing compilers. On one hand I really would like that we have the gccgo option; on the other hand I am wary of the requirements and I don't want to create something that is hard to maintain (not because I don't want to put the effort in, but because Go is a simple language and it shouldn't need jumping through many hoops to maintain). One way we *can* support both compilers is if we distribute third party Go packages as source instead of .a archives. Go binaries and packages are built with the "go" tool anyway, the compiler is now rarely invoked manually. I'm not really sure about this approach, one of the nice things about our current strategy is that like all other non Go packages we distribute, we can provide a level of guarantee that the package is usable, and will compile with the version of Go we ship. Cheers the noo, Graham -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org