pkg/52548: GDB breakpoint does not work properly in the binary created with golang on NetBSD (both pkgsrc/lang/go and pkgsrc/lang/go14).

[oshima-ya%yagoto-urayama.jp@localhost]

>Number:         52548
>Category:       pkg
>Synopsis:       GDB breakpoint does not work properly in the binary created with golang on NetBSD (both pkgsrc/lang/go and pkgsrc/lang/go14).
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 17 17:50:00 +0000 2017
>Originator:     Yasushi Oshima
>Release:        pkgsrc-current at Sep 16, 2017
>Organization:
>Environment:
NetBSD amanatsu5 8.0_BETA NetBSD 8.0_BETA (XEN3PAE_DOMU) #0: Sat Sep 16 02:41:54 JST 2017  oshima@sudachi:/export/netbsd-8/20170916/obj/i386/sys/arch/i386/compile/XEN3PAE_DOMU i386
>Description:
When debugging the binary created by golang with gdb, the breakpoint does not work properly.

For example:
- hello.go:
 package main
 import "fmt"
 func main(){
        fmt.Println("Hello world.");
 }
- build and run:
 $ go build hello.go
 $ file ./hello
 ./hello: ELF 32-bit LSB executable, Intel 80386, version 1 (NetBSD), statically linked, for NetBSD 5.99, with debug_info, not stripped
 $ ./hello
 Hello world

When run it on gdb and set breakpoint at any line of source code, this program will stop in another point with SIGTRAP.

 $ gdb ./hello
   (snip)
 Reading symbols from ./hello...done.
 warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts of file /home/oshima/hello.
 Use `info auto-load python-scripts [REGEXP]' to list them.
 (gdb) b main.main
 Breakpoint 1 at 0x80ba420: file /home/oshima/hello.go, line 3.
 (gdb) list
 1       package main
 2       import "fmt"
 3       func main(){
 4               fmt.Println("Hello World!")
 5       }
 (gdb) info b
 Num     Type           Disp Enb Address    What
 1       breakpoint     keep y   0x080ba420 in main.main
                                            at /home/oshima/hello.go:
 (gdb) r
 Starting program: /home/oshima/hello

 Program received signal SIGTRAP, Trace/breakpoint trap.
 runtime.lwp_park () at /usr/pkg/go/src/runtime/sys_netbsd_386.s:342
 342             MOVL    AX, ret+16(FP)

After this, this process cannot be continued. 

 (gdb) c
 Program received signal SIGSEGV, Segmentation fault.
 runtime.lwp_park () at /usr/pkg/go/src/runtime/sys_netbsd_386.s:342
 342             MOVL    AX, ret+16(FP)

This will occur only when statically linked. When dynamically linked, it works well.

 $ go build -ldflags '-linkmode external' hello.go
 $ gdb ./hello
 $ file ./hello
./hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 8.0, with debug_info, not stripped
 $ gdb ./hello
   (snip)
 (gdb) b main.main
 Breakpoint 1 at 0x80ba3c0: file /home/oshima/hello.go, line 3.
 (gdb) r
 Starting program: /home/oshima/hello
 [New LWP 4]
 [New LWP 3]
 [New LWP 2]

 Thread 1 hit Breakpoint 1, main.main () at /home/oshima/hello.go:3
 3       func main(){
 (gdb) c
 Continuing.
 Hello World!
 [Inferior 1 (LWP 0) exited normally]
 (gdb)

This problem occurs with both lang/go14 and lang/go.
 $ go version
 go version go1.9 netbsd/386
 $ /usr/pkg/go14/bin/go version
 go version go1.4.3 netbsd/386

Also this occurs in either amd64 or i386 (or arm).

Of course on Linux, even if it is statically linked binary, it stops correctly with the breakpoint.

>How-To-Repeat:
1. Build a go program
hello.go:
 package main
 import "fmt"
 func main(){
        fmt.Println("Hello world.");
 }
 $ go build hello.go

2. Run gdb 
 $ gdb ./hello

3. Set breakpoint on Go's main
 (gdb) b main.main

4. Run
 (gdb) r

>Fix:
I don't know.