NetBSD Problem Report #52548

From www@NetBSD.org  Sun Sep 17 17:47:13 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A2E227A263
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 17 Sep 2017 17:47:13 +0000 (UTC)
Message-Id: <20170917174712.A225F7A297@mollari.NetBSD.org>
Date: Sun, 17 Sep 2017 17:47:12 +0000 (UTC)
From: oshima-ya@yagoto-urayama.jp
Reply-To: oshima-ya@yagoto-urayama.jp
To: gnats-bugs@NetBSD.org
Subject: GDB breakpoint does not work properly in the binary created with golang on NetBSD (both pkgsrc/lang/go and pkgsrc/lang/go14).
X-Send-Pr-Version: www-1.0

>Number:         52548
>Notify-List:    bsiegert@NetBSD.org
>Category:       kern
>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:    kamil
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 17 17:50:00 +0000 2017
>Closed-Date:    Tue Jun 04 12:26:25 +0000 2019
>Last-Modified:  Tue Jun 04 12:26:25 +0000 2019
>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.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->kamil
Responsible-Changed-By: kamil@NetBSD.org
Responsible-Changed-When: Mon, 18 Sep 2017 22:42:39 +0200
Responsible-Changed-Why:
Take this.
This bug is likely caused by the fact that this go program uses more than 1 thread.
This scenario is now broken in ptrace(2). This is a kernel bug and I will work on it in close future.


State-Changed-From-To: open->closed
State-Changed-By: kamil@NetBSD.org
State-Changed-When: Tue, 04 Jun 2019 14:26:25 +0200
State-Changed-Why:
Fixed in HEAD as of 2019-06-04 with kernel and GDB changes.

Verified with static and dynamic go example code.

If there are still any issues, please report a new bug.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.