I hoped they would fix how the linker uses private OS calls.
Building a Better Go Linker
11–20 of 104 posts
Re: Building a Better Go Linker
#12> its implementation fit in one Turing award winner’s head What a great unit of measure :)
Wait, how many London buses fit in a Turing award winner's head? And can they all fit in to Wales despite the number of Olympic sized swimming pools already there?
Convert to Sydney harbours and add a banana for scale
Re: Building a Better Go Linker
#13I love to see that at the end the document the plugins package is mentioned. Currently it doesn't have support for Windows (among other issues), so it's really good to hear that the work in the linker might eventually improve the situation with plugins too, and that at least it's being kept in mind. On golang, interfaces being implemented implicitly is not everyone's cup of tea, and I can understand why, but when you combine that property with plugins, you can make really powerful plugin systems that use very simple code to work.
Re: Building a Better Go Linker
#14Any recommendations on resources to better understand the build process for compiled languages in general, and Go in particular?
Re: Building a Better Go Linker
#15Any recommendations on resources to better understand the build process for compiled languages in general, and Go in particular?
Re: Building a Better Go Linker
#16I don't get it. A linker's task should be straightforward. In essence, it looks up addresses from strings, whose number is bounded by the lines of code written by humans. I think that there must be a lot of incidental complexity if that task somehow becomes a bottleneck. And how can it be that a binary called "cmd/compile" has 170k symbols (that's like, global definitions, right?). Not that that's a huge number in te…
[deleted]
Re: Building a Better Go Linker
#17I hoped they would fix how the linker uses private OS calls.
[deleted]
Re: Building a Better Go Linker
#18I hoped they would fix how the linker uses private OS calls.
Which private OS calls. Can you site what they are?
Re: Building a Better Go Linker
#19Any recommendations on resources to better understand the build process for compiled languages in general, and Go in particular?
As weird as it sounds, Go is one of the easiest to understand compilers I've ever worked on. The language, and the implementation are relatively easy to understand and follow most of the standard compiler design and implementation texts. Similarly, since Go is so opinionated, the code is easy to read.
Re: Building a Better Go Linker
#20I don't get it. A linker's task should be straightforward. In essence, it looks up addresses from strings, whose number is bounded by the lines of code written by humans. I think that there must be a lot of incidental complexity if that task somehow becomes a bottleneck. And how can it be that a binary called "cmd/compile" has 170k symbols (that's like, global definitions, right?). Not that that's a huge number in te…
> that's like, global definitions, right? No, not just global definitions. Closures need linking, too. But the linker is doing much more than linking function entry points. Many automatic (on the stack) variables need linking so the GC can (a) trace the object graph and (b) move them when resizing the stack. Likewise, type definitions require metadata generation for GC tracing. And then there's all the debugging data…
Go currently does DWARF generation in the linker, but is in the process of moving that into the compiler. Also, most closures linking problems are relatively easy in Go.
As far as stack variables for the GC, the stack is exactly scanned for all but the last frame (I believe), but conservatively scanned for the last frame. This makes it much easier.
Types -- you're partially right. It is mostly all generated in the compiler, and deduped by the linker.
There's no reason Go's linker couldn't be much simpler and likely even simpler than a standard C linker. You might argue that Go will give up things like LTO, but Go designs out lots of the LTO problem (not PGO) by nature of how packages work, and the fact that there aren't cyclic dependencies.
Overall, the Go linker could be quite simple. It just needs some rework is all. :)