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

[zhangfannie]

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.

[zhangfannie]

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=, 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]

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]

CC @cherrymui

[ianlancetaylor]

I feel like you've skipped a few steps.

Does this only happens on linux-arm64?

Are you saying that pthread_attr_getstacksize sets size to the wrong value? Your debugger output doesn't seem to show the value of size.

[ianlancetaylor]

Also, what actually goes wrong?

[cherrymui]

As far as I can tell, nothing goes wrong.

Some background: @zhangfannie and I had some conversation in email about why writing to gsignal.stack.lo failed before CL https://go-review.googlesource.com/c/go/+/204519.

[zhangfannie]

@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=, 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 0xfffffffee2f0-size+4096
$7 = 0xffffff7ef2f0
(gdb) p/x 'runtime.g0'.stack
$5 = {lo = 0xffffff7ef2f0, hi = 0xfffffffee310}
(gdb) x 0xffffff7ef2f0
0xffffff7ef2f0: Cannot access memory at address 0xffffff7ef2f0

[ianlancetaylor]

Thanks. Perhaps the issue is that the default stack grows as needed. Or perhaps the thread default stack size simply isn't applicable to the main thread.

Any idea how we can determine the size of the stack here? I suppose we could always just guess. I'm not sure it matters much.

[zhangfannie]

@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.

[cherrymui]

Looks like a dup of #26061.