CODEWITHSUNDEEP
gocompiler-construction
Sam
Sam

Reputation: 4484

Understanding go tool compile and link commands

I understand that there are three steps involved in converting a high level language code to machine language or executable code namely - compiling, assembling, and linking.

As per go docs go tool compile does the following - It then writes a single object file named for the basename of the first source file with a .o suffix

So, the final object file must contain the machine language code (after compiling and assembling are run) of each file. If I pass go tool compile -S on the go file, it shows assembly language go generates.

After this when I run go tool link on the object file, it must link all required object files (if multiple) and then generate final machine language code (based on GOOS and GOARCH). It generates a file a.out

Have few basic questions here -

How do I know which variables and when are they going to be allocated memory in stack and heap? Does it matter if I generate executable for one machine and run on another with different architecture?

My test program

package main

func f(a *int, b *int) *int { 

    var c = (*a + *b); 
    var d = c;
    return &d;
}

func main() {
    var a = 2;
    var b = 6;

    f(&a,&b);
}

Result of go tool compile -m -l test.go

test.go:6: moved to heap: d
test.go:7: &d escapes to heap
test.go:3: f a does not escape
test.go:3: f b does not escape
test.go:14: main &a does not escape
test.go:14: main &b does not escape

Upvotes: 1

Views: 1977

Answers (1)

Volker
Volker

Reputation: 42432

In which step is the memory getting allocated?

It depends, some during linking, some during compiling, most during runtime (And some during loading).

How do I know which variables and when are they going to be allocated memory in stack and heap?

Ad hoc you do not know at all. The compiler decides this. If the compiler can prove that a variable does not escape it might keep it on the stack. Google for "golang escape analysis". There is a flag -m which makes the compiler output his decisions if you are interested in it.

Does it matter if I generate executable for one machine and run on another with different architecture?

No, but simply because this does not work at all: Executables are tied to architecture and won't run on a different one.

It seems you are mixing up compilation/linking and memory allocation. The later is pretty different from the former two. (Technically your linked program may contain memory and during loading it might get even more, but this is highly technical and architecture specific and really nothing to be concerned of).

Upvotes: 4

Related Questions