Open ppggff opened 1 year ago
In triage, we think this might be a bug in Delve, but it could be something in our DWARF information.
CC @aarzilli
Will look into it.
As far as I can tell it isn't delve, gdb can't get past runtime.sigtramp either:
(gdb) bt
#0 runtime.raise () at /home/ubuntu/goroot120/src/runtime/sys_linux_arm64.s:158
#1 0x0000000000054094 in runtime.dieFromSignal (sig=6) at /home/ubuntu/goroot120/src/runtime/signal_unix.go:879
#2 0x0000000000054598 in runtime.sigfwdgo (sig=6, info=<optimized out>, ctx=<optimized out>, ~r0=<optimized out>)
at /home/ubuntu/goroot120/src/runtime/signal_unix.go:1092
#3 0x00000000000530ac in runtime.sigtrampgo (sig=0, info=0x11c8, ctx=0x6)
at /home/ubuntu/goroot120/src/runtime/signal_unix.go:432
#4 0x000000000006c644 in runtime.sigtramp () at /home/ubuntu/goroot120/src/runtime/sys_linux_arm64.s:467
(gdb)
Gdb has a bunch of special code to get past sigtramp but I think it only works with glibc's sigtramp. One way to do this would be to cheat and add a workaround on delve's side and load the registers from the ctx argument of runtime.sigtrampgo. Another way would be to change the linker to emit a DFE for runtime.sigtrampgo (or runtime.sigtramp) that instructs the debugger to load registers from the ctx argument. Both are annoying because they have to be done for every architecture, doing it in delve would be easier purely because it supports fewer (but it isn't going to make gdb work).
For what it's worth, in runtime/sys_linux_amd64.s we carefully set up the signal handler so that gdb and gcc could backtrace through it: https://go.googlesource.com/go/+/refs/heads/master/src/runtime/sys_linux_amd64.s#460.
On arm64 the equivalent instructions are
0xd2801168 movz x8, #0x8b
0xd4000001 svc 0x0
Might be interesting to change sigreturn
in runtime/sys_linux_arm64.s to precisely that and see whether that fixes gdb.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?CentOS Linux release 7.9.2009 (AltArch) (qemu on apple m2 host)
go env
OutputWhat did you do?
test:
then build it, run it, and check the coredump with dlv:
What did you expect to see?
normal stack
What did you see instead?
endless runtime.sigtramp, for example: