profile
viewpoint

zhangfannie/go 0

The Go programming language

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

@cherrymui yes, id_aa64isar0_el1 is not accessible in user mode.

artooro

comment created time in 4 days

issue commentgolang/go

x/sys: Commit bc7efcf introduced a compilation error

@ianlancetaylor What about redefining Iovec{} struct as IovecArm64{] struct in unix/zptrace_armnn_linux.go file?

brotherlogic

comment created time in 3 months

issue commentgolang/go

sync/atomic: Load and Store don't use exclusive mode assembly instructions in arm64 weak memory model

Current go documentation does not specify any memory order guarantees made by the atomic operations, but there is some agreements on the memory order. Please refer to this CL https://go-review.googlesource.com/c/go/+/189417/ and this discussion https://groups.google.com/forum/#!msg/golang-dev/vVkH_9fl1D8/azJa10lkAwAJ.

The reason why CAS uses exclusive mode Load/Store instructions is to guarantee multiple opeations of a single process are atomic accesses. But there is no obvious reason that we have to use exclusive load/store instructions for atomic Load/Store.
Could you share why do you think need to use exclusive mode instructions?

Can you help to check your code to confirm whether it follows the rule "you shouldn't mix atomic and non-atomic accesses for a given memory word."? By the way, we also don't guarantee the memory order among atomic and non-atomic access on different memory.

Additional notes: The following is a description of these instructions in the arm architecture reference manual. LDAR: Load-Acquire Register derives an address from a base register value, loads a 32-bit word or 64-bit doubleword from memory, and writes it to a register STLR: Store-Release Register stores a 32-bit word or a 64-bit doubleword to a memory location, from a register. LDAXR: Load-Acquire Exclusive Register derives an address from a base register value, loads a 32-bit word or 64-bit doubleword from memory, and writes it to a register. The memory access is atomic. The PE marks the physical address being accessed as an exclusive access. STLXR: Store-Release Exclusive Register stores a 32-bit word or a 64-bit doubleword to memory if the PE has exclusive access to the memory address, from two registers, and returns a status value of 0 if the store was successful, or of 1 if no store was performed.The memory access is atomic.

WangLeonard

comment created time in 3 months

issue commentgolang/go

x/arch/armasm: thumb1/2 decoder not implemented

Yes, the current disassembler does not support thumb mode, but the current assembler does not generate thumb code. Therefore, if go code links the thumb native code, you can use binutils objdump to decode the program. @DKingCN Could you show me the scenario where you use the thumb decoder?

DKingCN

comment created time in 3 months

issue commentgolang/go

runtime: after g0.stack is adjusted in x_cgo_init(), g0.stack.lo cannot be accessed.

@cherrymui Thanks for providing the background. No errors have occurred so far. I just don't know if this behavior is correct and whether it will cause any potential issues, so I post it for discussion.

zhangfannie

comment created time in 3 months

issue commentgolang/go

runtime: after g0.stack is adjusted in x_cgo_init(), g0.stack.lo cannot be accessed.

@ianlancetaylor Please refer to for additional details. And the behavior of x86 is the same. Thank you. Loading Go Runtime support. (gdb) b gcc_linux_arm64.c:89 Breakpoint 1 at 0x48bb78: file gcc_linux_arm64.c, line 89. (gdb) r Starting program: /home/fanzha02/backup/testcase/testcodes/hello [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Breakpoint 1, x_cgo_init (g=0x569cc0 <runtime.g0>, setg=<optimized out>, tlsg=0x0, tlsbase=0xffffb7ff8700) at gcc_linux_arm64.c:89 89 g->stacklo = (uintptr)&size - size + 4096; (gdb) p/x 'runtime.g0'.stack $3 = {lo = 0xfffffffde310, hi = 0xfffffffee310} (gdb) p/x size $1 = 0x800000 (gdb) p/x &size $2 = 0xfffffffee2f0 (gdb) info proc mappings process 9890 Mapped address spaces:

      Start Addr           End Addr       Size     Offset objfile
        0x400000           0x544000   0x144000        0x0 /home/fanzha02/backup/testcase/testcodes/hello
        0x553000           0x554000     0x1000   0x143000 /home/fanzha02/backup/testcase/testcodes/hello
        0x554000           0x56a000    0x16000   0x144000 /home/fanzha02/backup/testcase/testcodes/hello
        0x56a000           0x5a7000    0x3d000        0x0 [heap]
  0xffffb7e37000     0xffffb7f77000   0x140000        0x0 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f77000     0xffffb7f86000     0xf000   0x140000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f86000     0xffffb7f8a000     0x4000   0x13f000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8a000     0xffffb7f8c000     0x2000   0x143000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8c000     0xffffb7f90000     0x4000        0x0
  0xffffb7f90000     0xffffb7fa7000    0x17000        0x0 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fa7000     0xffffb7fb6000     0xf000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb6000     0xffffb7fb7000     0x1000    0x16000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb7000     0xffffb7fb8000     0x1000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb8000     0xffffb7fbc000     0x4000        0x0
  0xffffb7fd2000     0xffffb7fef000    0x1d000        0x0 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7ff8000     0xffffb7ffc000     0x4000        0x0
  0xffffb7ffc000     0xffffb7ffd000     0x1000        0x0 [vvar]
  0xffffb7ffd000     0xffffb7ffe000     0x1000        0x0 [vdso]
  0xffffb7ffe000     0xffffb7fff000     0x1000    0x1c000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7fff000     0xffffb8001000     0x2000    0x1d000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xfffffffce000    0x1000000000000    0x32000        0x0 [stack]

(gdb) 90 pthread_attr_destroy(attr); (gdb) p/x &size-size+4096 $4 = 0xfffffbff62f0 (gdb) p/x 'runtime.g0'.stack $5 = {lo = 0xffffff7ef2f0, hi = 0xfffffffee310} (gdb) x 0xfffffbff62f0 0xfffffbff62f0: Cannot access memory at address 0xfffffbff62f0

zhangfannie

comment created time in 3 months

issue commentgolang/go

runtime: after g0.stack is adjusted in x_cgo_init(), g0.stack.lo cannot be accessed.

I also found that this would cause gsignal.stack.lo to be unreachable. Because adjustSignalStack() will set the gsignal stack of the current m to the g0 stack if the signal is delivered on the g0 stack.

zhangfannie

comment created time in 3 months

issue commentgolang/go

runtime: after g0.stack is adjusted in x_cgo_init(), g0.stack.lo cannot be accessed.

Please refer to the following debug information. hello.go package main import "fmt"

import "C"

func main() { fmt.Printf("Hello World") }

go build hello.go gdb ./hello (gdb) b gcc_linux_arm64.c:88 Breakpoint 1 at 0x48bb6c: file gcc_linux_arm64.c, line 88. (gdb) r Starting program: /home/fanzha02/backup/testcase/testcodes/hello [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". Breakpoint 1, x_cgo_init (g=0x569cc0 <runtime.g0>, setg=<optimized out>, tlsg=0x0, tlsbase=0xffffb7ff8700) at gcc_linux_arm64.c:88 88 pthread_attr_getstacksize(attr, &size); (gdb) i r x28 x28 0x569cc0 5676224 (gdb) p/x 'runtime.g0'.stack $1 = {lo = 0xfffffffde310, hi = 0xfffffffee310} // before the adjusting. (gdb) ni 89 g->stacklo = (uintptr)&size - size + 4096; (gdb) 90 pthread_attr_destroy(attr); (gdb) p/x 'runtime.g0'.stack $3 = {lo = 0xffffff7ef2f0, hi = 0xfffffffee310} // after adjusting. (gdb) x 0xffffff7ef2f0 0xffffff7ef2f0: Cannot access memory at address 0xffffff7ef2f0 // Now, the g0.stack.lo is not accessible. (gdb) info proc mappings process 9624 Mapped address spaces:

      Start Addr           End Addr       Size     Offset objfile
        0x400000           0x544000   0x144000        0x0 /home/fanzha02/backup/testcase/testcodes/hello
        0x553000           0x554000     0x1000   0x143000 /home/fanzha02/backup/testcase/testcodes/hello
        0x554000           0x56a000    0x16000   0x144000 /home/fanzha02/backup/testcase/testcodes/hello
        0x56a000           0x5a7000    0x3d000        0x0 [heap]
  0xffffb7e37000     0xffffb7f77000   0x140000        0x0 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f77000     0xffffb7f86000     0xf000   0x140000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f86000     0xffffb7f8a000     0x4000   0x13f000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8a000     0xffffb7f8c000     0x2000   0x143000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8c000     0xffffb7f90000     0x4000        0x0
  0xffffb7f90000     0xffffb7fa7000    0x17000        0x0 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fa7000     0xffffb7fb6000     0xf000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb6000     0xffffb7fb7000     0x1000    0x16000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb7000     0xffffb7fb8000     0x1000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb8000     0xffffb7fbc000     0x4000        0x0
  0xffffb7fd2000     0xffffb7fef000    0x1d000        0x0 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7ff8000     0xffffb7ffc000     0x4000        0x0
  0xffffb7ffc000     0xffffb7ffd000     0x1000        0x0 [vvar]
  0xffffb7ffd000     0xffffb7ffe000     0x1000        0x0 [vdso]
  0xffffb7ffe000     0xffffb7fff000     0x1000    0x1c000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7fff000     0xffffb8001000     0x2000    0x1d000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xfffffffce000    0x1000000000000    0x32000        0x0 [stack]
zhangfannie

comment created time in 3 months

issue openedgolang/go

runtime: after g0.stack is adjusted in x_cgo_init(), g0.stack.lo cannot be accessed.

In the initial process, go runtime(runtime.rt0_go()) calls _cgo_init() when using cgo, the x_cgo_init() extends g0.stack which causes g0.stack.lo cannot be accessed.

created time in 3 months

issue commentgolang/go

misc/cgo/testsanitizers: TestTSAN/tsan9 fails on arm64

But I think it is necessary to setg after sigFetchG, because the setGsignalStack() called by adjustSignalStack() uses getg() to get the wrong g.

zhangfannie

comment created time in 4 months

issue commentgolang/go

misc/cgo/testsanitizers: TestTSAN/tsan9 fails on arm64

The tsan9 case still fails with the fix CL https://golang.org/cl/204441 .

zhangfannie

comment created time in 4 months

issue commentgolang/go

misc/cgo/testsanitizers: TestTSAN/tsan9 fails on arm64

The tsan9 case still fails with the fix CL https://golang.org/cl/204441 .

zhangfannie

comment created time in 4 months

issue commentgolang/go

misc/cgo/testsanitizers: TestTSAN/tsan9 fails on arm64

  1. go build misc/cgo/testsanitizers/testdata/tsan9.go
  2. used gdb tool and found src/runtime/sys_linux_arm64.s:300 MOVD g, (R22) cause segment fault.
  3. The code is added by this CL https://go-review.googlesource.com/c/go/+/202759.
zhangfannie

comment created time in 4 months

issue openedgolang/go

misc/cgo/testsanitizers: TestTSAN/tsan9 fails on arm64

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +f4e32aeed1 Wed Oct 30 08:17:29 2019 +0000 linux/arm64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="arm64" GOBIN="" GOCACHE="/home/fanzha02/.cache/go-build" GOENV="/home/fanzha02/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="arm64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/fanzha02/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/fanzha02/work/go_project/golang" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/fanzha02/work/go_project/golang/pkg/tool/linux_arm64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/fanzha02/work/go_project/golang/src/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build943556601=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. --> run go tool dist test -run testsanitizers

What did you expect to see?

pass

What did you see instead?

../misc/cgo/testsanitizers

--- FAIL: TestTSAN (8.88s) --- FAIL: TestTSAN/tsan9 (3.29s) tsan_test.go:53: /tmp/TestTSAN118028569/tsan9 exited with signal: segmentation fault FAIL 2019/10/30 10:55:54 Failed: exit status 1

created time in 4 months

issue commentgolang/go

runtime: msanwrite segfaults when called without a g on arm64

@ianlancetaylor Yes, you are right. We need to check nil g to msancall() in runtime/msan_arm64.s. The fixed patch is ready and I will submit it. Thank you.

zhangfannie

comment created time in 5 months

issue commentgolang/go

runtime: msanwrite segfaults when called without a g on arm64

The cause is that when built with -buildmode=c-shared, the sigaction() of runtime/cgo_sigaction.go will call msanwrite() during libpreinit (before the runtime has set up a g). Unfortunately, on arm64, msancall() called by msanwrite() assumes that it is always called with a valid g, leading to a segfault.

I will submit the fixed CL, checking for nil g in msancall() on arm64.

zhangfannie

comment created time in 5 months

issue openedgolang/go

runtime: msanwrite segfaults when called without a g on arm64

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +c3c53661ba Tue Sep 17 04:37:46 2019 +0000 linux/arm64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="arm64" GOBIN="" GOCACHE="/home/fanzha02/.cache/go-build" GOENV="/home/fanzha02/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="arm64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/fanzha02/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/fanzha02/work/go_project/gomain" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/fanzha02/work/go_project/gomain/pkg/tool/linux_arm64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/fanzha02/work/go_project/gomain/src/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build714027259=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. --> Run testsanitizers/TestShared test

cd $GOROOT/src run the command: CC=clang ../bin/go tool dist test -run testsanitizers clang version: clang --version clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin

What did you expect to see?

pass

What did you see instead?

The test failed.

../misc/cgo/testsanitizers

--- FAIL: TestShared (0.24s) --- FAIL: TestShared/msan_shared (4.69s) cshared_test.go:71: /tmp/TestShared066999108/msan_shared exited with exit status 77 MemorySanitizer:DEADLYSIGNAL ==24668==ERROR: MemorySanitizer: SEGV on unknown address 0x000000000030 (pc 0xffff94b3e9d4 bp 0xffffef3ca388 sp 0xffffef3ca390 T24668) ==24668==The signal is caused by a READ memory access. ==24668==Hint: address points to the zero page. #0 0xffff94b3e9d3 (/tmp/TestShared066999108/libmsan_shared.so+0x8e9d3)

        MemorySanitizer can not provide additional info.
        SUMMARY: MemorySanitizer: SEGV (/tmp/TestShared066999108/libmsan_shared.so+0x8e9d3)
        ==24668==ABORTING

FAIL

created time in 5 months

more