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

On Mon, 19 Mar 2012, Cristian Rodríguez wrote:

El 19/03/12 07:16, Richard Guenther escribió:

...

And no, switching the default linker to gold is not a good idea IMHO given its lack of architecture support for s390 and ia64 (I suppose only x86 and arm are well-tested, not idea about the powerpc state).

Well, but what about switching to gold in those arches that it works or provide an easy way to use it when building packages ?

s390 could still use old LD and ia64..well, glibc has no support for IA64 any longer, it was removed a few months ago.

I believe gold does not support all the linker script features GNU ld does, especially I don't think gold can link the linux kernel. Can it? Richard. -- Richard Guenther SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

El 20/03/12 07:46, Richard Guenther escribió:

On Mon, 19 Mar 2012, Cristian Rodríguez wrote:

...

El 19/03/12 07:16, Richard Guenther escribió:

...

And no, switching the default linker to gold is not a good idea IMHO given its lack of architecture support for s390 and ia64 (I suppose only x86 and arm are well-tested, not idea about the powerpc state).

Well, but what about switching to gold in those arches that it works or provide an easy way to use it when building packages ?

s390 could still use old LD and ia64..well, glibc has no support for IA64 any longer, it was removed a few months ago.

I believe gold does not support all the linker script features GNU ld does, especially I don't think gold can link the linux kernel. Can it?

Richard.

Apparently, both the kernel and glibc needs to be linked with GNU ld.. so adding an option to use binutils-gold during build might be the best solution for now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 20 Mar 2012 11:46:12 Richard Guenther wrote:

On Mon, 19 Mar 2012, Cristian Rodríguez wrote:

...

El 19/03/12 07:16, Richard Guenther escribió:

...

And no, switching the default linker to gold is not a good idea IMHO given its lack of architecture support for s390 and ia64 (I suppose only x86 and arm are well-tested, not idea about the powerpc state).

Well, but what about switching to gold in those arches that it works or provide an easy way to use it when building packages ?

s390 could still use old LD and ia64..well, glibc has no support for IA64 any longer, it was removed a few months ago.

I believe gold does not support all the linker script features GNU ld does, especially I don't think gold can link the linux kernel. Can it?

[18:24] <iant> cenuij: the linux kernel sometimes works with gold and sometimes doesn't [18:24] <iant> glibc is very close but I think gold may need a couple more tweaks [18:25] <iant> roland mcgrath was looking at it a few months ago [18:25] <iant> he got it working but I don't know if all the patches are in Clearly we can't use this as a default, though I'm pretty sure some projects might benefit from using gold with LTO right now. Which is cool because we provide latest gold in binutils 2.22, so c++ hackers take note ;) Cheers the noo, Graham -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org