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:
(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.