Airs – Ian Lance Taylor

Gccgo in GCC

I committed the gccgo frontend to the mainline of gcc yesterday. Getting to this point was a long series of steps to get the various supporting patches approved. This means that gccgo will definitely be available in the gcc 4.6 release, which will happen sometime early next year.

There is still quite a lot of work to do, of course. Now that it’s in mainline, more people are going to try it on more targets. I’ve only been using GNU/Linux, and Vinu Rajashekhar ported it to RTEMS. Other targets will have problems. Also, the gccgo frontend is still intimately tied to gcc when it converts from the gccgo IR to the gcc IR. I want to increase that separation, so that the frontend proper is independent of gcc itself.

On the functionality side, the gccgo library uses a single operating system thread for each goroutine. That is not what 6g/8g do: they multiplex goroutines onto operating system threads. Multiplexing is more efficient for a language like Go, and I need to change gccgo to work that way.

I also plan to use some escape analysis recorded in the export information to track whether pointer arguments escape—whether they are stored in memory. If a pointer argument does not escape, then it does not need to be pushed onto the heap. My hope is that implementing that will significantly reduce the amount of garbage that is created, and therefore reduce the amount of work that the garbage collector has to do.

Release gccgo in gcc is going to introduce a difficulty for Go programmers who use it. The Go language continues to evolve, but gcc 4.6 will not. That means that people using gcc 4.6 will be using a language which will be increasingly out of date. I don’t think there is any way to avoid that problem at this stage. The language will become more stable over time.

So this is just one more step along the way, but it’s a major one, and I’m very glad that it is finally done.

Posted

in

by

Ian Lance Taylor

Tags:

Comments

7 responses to “Gccgo in GCC”

  1. fche Avatar
    fche

    Have you folks considered including a language-version-sensitive conditional in the language? It could be used for turning off newer features, or for selectively using them, or signalling errors in case of incompatibility. If so, better add it early than late.

  2. Ian Lance Taylor Avatar
    Ian Lance Taylor

    Go doesn’t have a preprocessor, and, because of syntax changes, it would really have to be a preprocessor. So, good idea, but that approach doesn’t fit the language.

  3. vsrinivas Avatar
    vsrinivas

    Neat work; does the gccgo runtime include a garbage collector nowadays?

  4. Ian Lance Taylor Avatar
    Ian Lance Taylor

    Yes, gccgo uses the same simple mark and sweep garbage collector that 6g/8g use.

  5. Ryan Hill Avatar
    Ryan Hill

    I’ve noticed that the .gox files that are installed have writable executable sections since they are just created with `objcopy -j .go_export`. This makes our package manager, which uses scanelf [1] to look for such things, very upset. Is there an easy way to avoid this?

    Also the libgo shared library itself has an executable stack. Is this necessary for split stacks?

    [1] http://www.gentoo.org/proj/en/hardened/pax-utils.xml

  6. Ian Lance Taylor Avatar
    Ian Lance Taylor

    Thanks for the note, but it probably makes more sense to report bugs at http://gcc.gnu.org/bugzilla/ or http://code.google.com/p/go/issues/ .

    When I look at the installed .gox files, the .go_export sections are neither writable nor executable. What version of objcopy are you using? Perhaps this has been fixed, or broken. I’m using 2.20.1. In any case, the .gox files are not executables. It’s not clear to me that scanelf should care about object files, though perhaps it makes sense to prevent people from linking those files into their programs, not that that would happen with .gox files.

    The fact that libgo is marked as requiring an executable stack is actually a bug in gcc and/or gccgo. It does not require an executable stack. It does currently mmap sections are both writable and executable, though, which will not work on an SELinux system. There are a couple of ways to fix that, I’m not sure what I’ll do.

  7. Ryan Hill Avatar
    Ryan Hill

    Looking into this further I think scanelf is being overzealous. It seems to treat any ELF without a .note.GNU-stack section as suspect. I’ll take it up with them.

    Thanks.

Leave a Reply