Golang Building from Source

Getting Help
1

I have been working on a research project that involves Garbage collection mechanisms in Golang. We have successfully built Golang from source code. Now, we are trying to add minor modifications in the source code and see if build succeeds or not. As a starter, we have added a log print in mgc.go file in function gcinit at the very beginning

func gcinit() {
	log.Print("In Function GCINT ")
}

After adding the log print, the build fails with the following error:

In Function GCINIT 
            In Function GCINIT shift.go:12:6: (i8 + 1) (8 bits) too small for shift of 8
FAIL
FAIL    cmd/vet    9.460s
FAIL
go tool dist: Failed: exit status 1

We have tried to use fmt.printf but no luck so far. We will be happy if someone can help

2

Hi @jaintapauljp,

I could imagine that the fmt package causes problems.

Did you try the built-in print or println functions?

3

Hi @christophberger , thanks for the suggestion. It still fails with the following message:

  --- FAIL: TestVet/rangeloop (0.46s)
        vet_test.go:146: error check failed: 
            Unmatched Errors:
4

The errors appear to come from running go test on the sources of the vet command.

I cannot see any connection between mgc.go that you modified and the files shift.go and vet_test.go that belong to the unit tests for the vet command.

Do I understand the situation correctly: the rangeloop test fails reproducibly if you add a call to the built-in function println() to func gcinit() in runtime/mgc.go?

All else is vanilla code?

5

You are right about the problem. We only added a line in the gcinit function and that causes the fail. If we remove the line, the build works fine.

6

I got curious and installed the Go source following the steps in Installing Go from source - The Go Programming Language.

Then I changed src/runtime/mgc.go to include the println call:

 func gcinit() {
	println("GCINIT")
	// rest of gcinit

Then I ran ./all.bash in the goroot directory. The compilation succeeded.

The first test that fails is:

ok  	regexp/syntax	1.042s
--- FAIL: TestLockRankGenerated (0.15s)
    lockrank_test.go:20: exit status 1
--- FAIL: TestSUID (0.11s)
    crash_test.go:138: running go build -o /var/folders/_m/dgnkqt8d3j10svk5c06px4vc0000gn/T/go-build2564578370/testsuid.exe
    security_test.go:82: building testsuid []: exit status 1
        # runtime
        ../../mgc.go:153:13: newline in string
        ../../mgc.go:153:13: syntax error: unexpected newline in argument list; possibly missing comma or )
        ../../mgc.go:154:2: syntax error: unexpected if at end of statement

Other tests fail in these ways:

--- FAIL: TestTrampoline (1.00s)
    link_test.go:690: unexpected output (default):
        GCINIT
        hello

--- FAIL: TestRuntimeTypeAttrInternal (0.77s)
    dwarf_test.go:776: could not parse type address from program output "GCINIT\n4311591584": strconv.ParseUint: parsing "GCINIT\n4311591584": invalid syntax

--- FAIL: TestHello (27.07s)
    pack_test.go:221: incorrect output: "GCINIT\nhello world\n", want "hello world\n"
FAIL

It looks like the first and foremost problem is that print / println messes with stdout.

7

Please let me know if you find a solution for this scenario. I am really stuck with this.

8

All I can tell right now is that any function that writes to stdout (and probably stderr, too) invalidates multiple tests.

I have to take a guess, but the file debuglog.go (in src/runtime) looks interesting. It provides an in-memory debugger. When the app panics, the log output gets written to stdout.

From the file comments, it seems that debuglog.go is ideal for logging activity inside the runtime:

dlog can be used from highly-constrained corners of the runtime: it is safe to use in the signal handler, from within the write barrier, from within the stack implementation, and in places that must be recursively nosplit.

9

Thanks. I will try to use it as per your suggestion. I will let you know if that works for me.

1 Like
10

Can you specify the steps to reproduce? I want to build it from source as well…seems intriguing

11

Hi , I tried to use the debuglog but yet I failed.

12

@jaintapauljp sorry for the late reply. I am afraid I ran out of ideas. Using debuglog was a quick idea drawn from looking at the sources. Maybe someone who is experienced with building Go from source can help further.

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.