cmd/compile: CL 98415 seems to have broken some MIPS and PPC64 builders

[mvdan]

For example:

https://build.golang.org/log/e0e92d72d0a3ca60d2b158135c420739dc0b7308
https://build.golang.org/log/956610b6addc3783bca4ef6f9b4a784581a9693e
https://build.golang.org/log/1718e9a596ccee492fc8e5c7f7814122bd147024

The error is usually along the lines of:

--- FAIL: TestGdbBacktrace (2.26s)
	runtime-gdb_test.go:59: gdb version 7.9
	runtime-gdb_test.go:345: could not find '#0.*main\.eee' in backtrace
	runtime-gdb_test.go:346: gdb output:
		warning: File "/data/mips/go/src/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
		To enable execution of this file add
			add-auto-load-safe-path /data/mips/go/src/runtime/runtime-gdb.py
		line to your configuration file "/mips/proj/build-compiler/upstream-testing/go-lang/.gdbinit".
		To completely disable this security protection add
			set auto-load safe-path /
		line to your configuration file "/mips/proj/build-compiler/upstream-testing/go-lang/.gdbinit".
		For more information about this security protection see the
		"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
			info "(gdb)Auto-loading safe path"
		Breakpoint 1 at 0x67664: main.eee. (2 locations)
		
		Breakpoint 1, main.ddd (~r0=<optimized out>) at /tmp/go-build199996638/main.go:14
		14	func ddd() bool { return f() }
		#0  main.ddd (~r0=<optimized out>) at /tmp/go-build199996638/main.go:14
		#1  0x0006764c in main.ccc (~r0=<optimized out>) at /tmp/go-build199996638/main.go:11
		#2  0x00067600 in main.bbb (~r0=<optimized out>) at /tmp/go-build199996638/main.go:8
		#3  0x000675b4 in main.aaa (~r0=<optimized out>) at /tmp/go-build199996638/main.go:5
		#4  0x00067700 in main.main () at /tmp/go-build199996638/main.go:22
		
		Breakpoint 1, main.eee (~r0=<optimized out>) at /tmp/go-build199996638/main.go:17
		17	func eee() bool { return true }
FAIL
FAIL	runtime	146.377s

Note that these builders were already somewhat flakey, as can be seen on the build dashboard. But after that CL, they seem to almost always fail with this error.

/cc @dr2chase @randall77 @aclements @cherrymui

[mengzhuo]

same as arm64

--- FAIL: TestGdbBacktrace (2.99s)
        runtime-gdb_test.go:59: gdb version 7.12
        runtime-gdb_test.go:345: could not find '#0.*main\.eee' in backtrace
        runtime-gdb_test.go:346: gdb output:
                warning: File "/root/godev/src/runtime/runtime-gdb.py" auto-loading has been declined by your `
auto-load safe-path' set to "$debugdir:$datadir/auto-load".
                To enable execution of this file add
                        add-auto-load-safe-path /root/godev/src/runtime/runtime-gdb.py
                line to your configuration file "/root/.gdbinit".
                To completely disable this security protection add
                        set auto-load safe-path /
                line to your configuration file "/root/.gdbinit".
                For more information about this security protection see the
                "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
                        info "(gdb)Auto-loading safe path"
                Breakpoint 1 at 0x56b10: main.eee. (2 locations)
                [New LWP 16406]
                [New LWP 16412]
                [New LWP 16413]
                [New LWP 16414]

                Thread 1 "a.exe" hit Breakpoint 1, main.ddd (~r0=<optimized out>) at /tmp/go-build289574404/mai
n.go:14
                14      func ddd() bool { return f() }
                #0  main.ddd (~r0=<optimized out>) at /tmp/go-build289574404/main.go:14
                #1  0x0000000000056ae8 in main.ccc (~r0=<optimized out>) at /tmp/go-build289574404/main.go:11
                #2  0x0000000000056aa8 in main.bbb (~r0=<optimized out>) at /tmp/go-build289574404/main.go:8
                #3  0x0000000000056a68 in main.aaa (~r0=<optimized out>) at /tmp/go-build289574404/main.go:5
                #4  0x0000000000056b88 in main.main () at /tmp/go-build289574404/main.go:22

                Thread 1 "a.exe" hit Breakpoint 1, main.eee (~r0=<optimized out>) at /tmp/go-build289574404/mai
n.go:17
                17      func eee() bool { return true }
FAIL

[dr2chase]

I will look at this, I am happy to see a failure on arm64 since I actually have easy access to one of those.

[laboger]

Not sure if this helps, but I tried this on a ppc64le system and here is what I see when I try to use gdb on the test program:

(gdb) break main.eee
Breakpoint 1 at 0x5b4a0: main.eee. (2 locations)
(gdb) run
Starting program: /home/boger/gotests/gdb/main 
Trying host libthread_db library: libthread_db.so.1.
Host libthread_db.so.1 resolved to: /lib/powerpc64le-linux-gnu/libthread_db.so.1.
td_ta_new failed: application not linked with libthread
thread_db_load_search returning 0
[New LWP 21710]
[New LWP 21711]
[New LWP 21712]
[New LWP 21713]
[New LWP 21714]

Thread 1 "main" hit Breakpoint 1, main.ddd (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:13
13	func ddd() bool { return f() }
(gdb) bt
#0  main.ddd (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:13
#1  0x000000000005b484 in main.ccc (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:10
#2  0x000000000005b444 in main.bbb (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:7
#3  0x000000000005b404 in main.aaa (~r0=<optimized out>) at /home/boger/gotests/gdb/main.go:4
#4  0x000000000005b524 in main.main () at /home/boger/gotests/gdb/main.go:21
(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
	breakpoint already hit 1 time
1.1                         y     0x000000000005b4a0 in main.ddd at /home/boger/gotests/gdb/main.go:13
1.2                         y     0x000000000005b4f4 in main.eee at /home/boger/gotests/gdb/main.go:16
(gdb) 

Setting the breakpoint at main.eee also seems to be setting it at main.ddd in the latest.

I tried the same thing with a toolchain that's a bit older and it only set 1 breakpoint and the gdb traceback output looks right.

[gopherbot]

Change https://golang.org/cl/104955 mentions this issue: cmd/compile: ensure first instruction of function is stmt

[dr2chase]

@laboger That helps -- it's the exact same failure as arm64. First instruction isn't marked as a statement, so gdb "isn't sure" if the 0x5b4a0 is in eee or the function containing the previous statement, which is ddd, so it sets breakpoints in both places.

[laboger]

That fixes it.

[mvdan]

The PPC64 builders are already happy :) Thanks @dr2chase!

[mengzhuo]

arm64 is happy too

Thanks @dr2chase