From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BFA183858D37; Mon, 3 Apr 2023 12:00:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BFA183858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680523200; bh=z34LWI3hPH9KuDi2+O19wwaMXe1oa3eVP4VH+va/OuY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XndpWhyMsA1xg6/k0EToLdCeg0YVrkdW81eICXu+xYsers5tuyktKgPdm1zaaLbMs 69bBH48lg/G6gyDl/vA3oFxk3JJUukIVKFo4SftsLn8MJPcIXWAMlOmsm71xzEvp8X a+s0uYqLwrrk8QmZfG+Rexhbk8l1ILdcAmHeU4qk= From: "mariappan.balraj at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug go/30038] When using CGO and C code is calling GO function, not getting call stack of C from core dump. Only getting call stack of GO. Date: Mon, 03 Apr 2023 11:59:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: go X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: mariappan.balraj at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30038 --- Comment #17 from mariappan balraj -= -- Hello GDB experts, When GO functions calls C function, it switches stack to use system stack. There are 2 stack Go stack and system stack. Go stack is used for GO functi= ons and system stack are used for C functions. When I use gdb to do live debugging, I am able to see GO stack trace before C function is getting cal= led. When the C function is called, the stack is switched to system stack. In th= is case, GDB is displaying only the C stack. But by using the RBP, I am able to manually decode the Go stack. Could you please fix it? //test.go package main /* #include void test1(void) { printf("Welcome"); } void test2(void) { int val =3D 2; test1(); } void test3(void) { int val =3D 3; test2(); } */ import "C" func test5() { C.test3() } func test4() { test5() } func main() { test4() } Command used to build: CGO_CFLAGS=3D"-g" go build -compiler gc -gcflags=3Dall=3D"-N -l" test.go #gdb ./test (gdb) break main.test5 Breakpoint 1 at 0x464280: file /home/soomohan/mbalraj/test_gdb/test.go, line 22. (gdb) run Starting program: /home/soomohan/mbalraj/test_gdb/test=20 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x15552df4a640 (LWP 1007325)] [New Thread 0x15552dd49640 (LWP 1007326)] [New Thread 0x15552db08640 (LWP 1007327)] [New Thread 0x15552d907640 (LWP 1007328)] [New Thread 0x15552d6c6640 (LWP 1007329)] Thread 1 "test" hit Breakpoint 1, main.test5 () at /home/soomohan/mbalraj/test_gdb/test.go:22 22 func test5() { (gdb) bt #0 main.test5 () at /home/soomohan/mbalraj/test_gdb/test.go:22 #1 0x00000000004642d7 in main.test4 () at /home/soomohan/mbalraj/test_gdb/test.go:27 #2 0x0000000000464317 in main.main () at /home/soomohan/mbalraj/test_gdb/test.go:31 (gdb) break test1 Breakpoint 2 at 0x46436e: file /home/soomohan/mbalraj/test_gdb/test.go, lin= e 7. (gdb) c Continuing. Thread 1 "test" hit Breakpoint 2, test1 () at /home/soomohan/mbalraj/test_gdb/test.go:7 7 printf("Welcome"); (gdb) bt #0 test1 () at /home/soomohan/mbalraj/test_gdb/test.go:7 #1 0x000000000046439d in test2 () at /home/soomohan/mbalraj/test_gdb/test.go:12 #2 0x00000000004643b8 in test3 () at /home/soomohan/mbalraj/test_gdb/test.go:17 #3 0x00000000004643d8 in _cgo_b6b18ee597cc_Cfunc_test3 (v=3D0xc000048f50) = at /tmp/go-build/cgo-gcc-prolog:49 #4 0x000000000045f2e4 in runtime.asmcgocall () at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848 #5 0x00000000004e3460 in ?? () #6 0x0000000000000001 in ?? () #7 0x000000c000104100 in ?? () #8 0x0a007fffffffdfe8 in ?? () #9 0x0000000000000001 in ?? () #10 0x0000000000000118 in ?? () #11 0x000000c000006340 in ?? () #12 0x000000c000048f50 in ?? () #13 0x000000000045f20b in runtime.morestack () at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:574 #14 0x0000000000461da5 in runtime.newproc (fn=3D0x1) at :1 #15 0x00000000004cc720 in runtime[scavenger] () #16 0x0000000000000001 in ?? () #17 0x000000000045f025 in runtime.mstart () at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:394 #18 0x000000000045efaf in runtime.rt0_go () at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:358 #19 0x0000000000000001 in ?? () #20 0x00007fffffffe168 in ?? () #21 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x00000000004643d8 in _cgo_b6b18ee597cc_Cfunc_test3 (v=3D0xc000048f50) = at /tmp/go-build/cgo-gcc-prolog:49 (gdb) info reg rbp 0x7fffffffdfa0 0x7fffffffdfa0 rip 0x4643d8 0x4643d8 <_cgo_b6b18ee597cc_Cfunc_test3+= 29> (gdb) x /4 0x7fffffffdfa0 0x7fffffffdfa0: 0x00048f18 0x000000c0 0x0045f2e4 0x00000000 (gdb) disassemble 0x0045f2e4 Dump of assembler code for function runtime.asmcgocall: 0x000000000045f280 <+0>: mov 0x8(%rsp),%rax (gdb) x /4 0x000000c000048f40=20 0xc000048f40: 0x00048f50 0x000000c0 0x00464297 0x00000000 (gdb) disassemble 0x00464297 Dump of assembler code for function main.test5: (gdb) x /4 0x000000c000048f50=20 0xc000048f50: 0x00048f60 0x000000c0 0x004642d7 0x00000000 (gdb) disassemble 0x004642d7 Dump of assembler code for function main.test4: (gdb) x /4 0x000000c000048f60=20 0xc000048f60: 0x00048f70 0x000000c0 0x00464317 0x00000000 (gdb) disassemble 0x00464317 Dump of assembler code for function main.main: (gdb) x /4 0x000000c000048f70 0xc000048f70: 0x00048fd0 0x000000c0 0x00437073 0x00000000 (gdb) disassemble 0x00437073 Dump of assembler code for function runtime.main: (gdb) x /4 0x000000c000048fd0 0xc000048fd0: 0x00000000 0x00000000 0x0045f5e1 0x00000000 (gdb) disassemble 0x0045f5e1 Dump of assembler code for function runtime.goexit: Finally the stack should like as follows: (dlv) bt 0 0x000000000046436e in C.test1 at ./test.go:7 1 0x000000000046439d in C.test2 at ./test.go:12 2 0x00000000004643b8 in C.test3 at ./test.go:17 3 0x00000000004643d8 in C._cgo_b6b18ee597cc_Cfunc_test3 at /tmp/go-build/cgo-gcc-prolog:49 4 0x000000000045f2e4 in runtime.asmcgocall at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848 5 0x00000000004643bb in C._cgo_b6b18ee597cc_Cfunc_test3 at /tmp/go-build/cgo-gcc-prolog:44 6 0x0000000000404f0a in runtime.cgocall at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167 7 0x0000000000464245 in main._Cfunc_test3 at _cgo_gotypes.go:39 8 0x0000000000464297 in main.test5 at ./test.go:23 9 0x00000000004642d7 in main.test4 at ./test.go:27 10 0x0000000000464317 in main.main at ./test.go:31 11 0x0000000000437073 in runtime.main at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250 12 0x000000000045f5e1 in runtime.goexit at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598 --=20 You are receiving this mail because: You are on the CC list for the bug.=