[Bug go/30038] New: 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.

[Bug go/30038] New: 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.

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

            Bug ID: 30038
           Summary: 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.
           Product: gdb
           Version: 12.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: go
          Assignee: unassigned at sourceware dot org
          Reporter: mariappan.balraj at gmail dot com
  Target Milestone: ---

Following is the source code:

//test.go
package main

/*
#include <stdio.h>

extern void Test4(void);

void test1(void) {
   Test4();
}

void test2(void) {
    int val = 2;
    test1();
}

void test3(void) {
    int val = 3;
    test2();
}
*/
import "C"

func main() {
    C.test3()
}

//export.go
import "C"

//export Test4
func Test4() {
    panic("Panic inside Test4")
}

Process crashed because of PANIC from Test4().
test3() is called from GO code. test3() is calling test2() and which is calling
test1() and which is calling Test4() Go function. Not seeing test3(), test2()
and test1() in the back trace of core dump. This is very important for
debugging when CGO is used. 

#gdb ./test core.242083
//Back trace
(gdb) bt
#0  runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
#1  0x0000000000443385 in runtime.dieFromSignal (sig=6) at
/usr/local/go/src/runtime/signal_unix.go:871
#2  0x000000000044391e in runtime.sigfwdgo (sig=6, info=<optimized out>,
ctx=<optimized out>, ~r0=<optimized out>) at
/usr/local/go/src/runtime/signal_unix.go:1087
#3  0x0000000000442027 in runtime.sigtrampgo (sig=0, info=0x0, ctx=0x458401
<runtime.raise+33>) at /usr/local/go/src/runtime/signal_unix.go:432
#4  0x00000000004586e6 in runtime.sigtramp () at
/usr/local/go/src/runtime/sys_linux_amd64.s:359
#5  <signal handler called>
#6  runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
#7  0x0000000000443385 in runtime.dieFromSignal (sig=6) at
/usr/local/go/src/runtime/signal_unix.go:871
#8  0x000000000042f9a9 in runtime.crash () at
/usr/local/go/src/runtime/signal_unix.go:963
#9  runtime.fatalpanic (msgs=<optimized out>) at
/usr/local/go/src/runtime/panic.go:1170
#10 0x000000000042f07a in runtime.gopanic (e=...) at
/usr/local/go/src/runtime/panic.go:987
#11 0x000000000045ac07 in main.Test4 () at
/home/ubuntu/mbalraj/GO/TEST/TEST4/export.go:7
#12 _cgoexp_040b784f82f8_Test4 (a=<optimized out>) at _cgo_gotypes.go:51
#13 0x0000000000404a82 in runtime.cgocallbackg1 (fn=0x45abe0
<_cgoexp_040b784f82f8_Test4>, frame=0x7fff8d239d27, ctxt=0) at
/usr/local/go/src/runtime/cgocall.go:316
#14 0x0000000000404709 in runtime.cgocallbackg (fn=0x45abe0
<_cgoexp_040b784f82f8_Test4>, frame=0x7fff8d239d27, ctxt=0) at
/usr/local/go/src/runtime/cgocall.go:235
#15 0x0000000000458d8f in runtime.cgocallbackg (fn=0x45abe0
<_cgoexp_040b784f82f8_Test4>, frame=0x7fff8d239d27, ctxt=0) at
<autogenerated>:1
#16 0x0000000000456934 in runtime.cgocallback () at
/usr/local/go/src/runtime/asm_amd64.s:994
#17 0x0000000000456600 in ?? ()
#18 0x0000000000404585 in runtime.cgocall (fn=0x45acb0
<_cgo_040b784f82f8_Cfunc_test3>, arg=0xc000058f70, ~r0=<optimized out>) at
/usr/local/go/src/runtime/cgocall.go:168
#19 0x000000000045ab85 in main._Cfunc_test3 (r1=...) at _cgo_gotypes.go:41
#20 0x000000000045abb7 in main.main () at
/home/ubuntu/mbalraj/GO/TEST/TEST4/test.go:25

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

mariappan balraj <mariappan.balraj at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mariappan.balraj at gmail dot com
           Priority|P2                          |P1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Could you say how to compile this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #2 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hi Tom Tromey,

Thanks for looking into this.

Please find the steps:
1) Create a directory named TEST
2) In TEST create 2 GO files, test.go and export.go

===>test.go

package main

/*
#include <stdio.h>

extern void Test4(void);

void test1(void) {
   Test4();
}

void test2(void) {
    int val = 2;
    test1();
}

void test3(void) {
    int val = 3;
    test2();
}
*/
import "C"

func main() {
    C.test3()
}

===>export.go

package main

import "C"

//export Test4
func Test4() {
    panic("Panic inside Test4")
}

3) Run "go mod init test"
4) Run "go mod tidy"
5) Run "go build ."
6) Run "sudo su"
7) Run "ulimit -c unlimited"
8) Run "echo "core" > /proc/sys/kernel/core_pattern"
9) Run "GOTRACEBACK=crash ./test"
10) Run "gdb ./test core.243539"

Best Regards
Mariappan

On Tue, Jan 24, 2023 at 6:39 PM tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>
> Tom Tromey <tromey at sourceware dot org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |tromey at sourceware dot
> org
>
> --- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
> Could you say how to compile this?
>
> --
> You are receiving this mail because:
> You reported the bug.
> You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #3 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Any update on this issue? Helping to resolve this issue is really help us a
lot. Kindly please help.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #4 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hello GDB experts,

Can someone please help to resolve this issue?

Best Regards
Mariappan

On Wed, Jan 25, 2023 at 10:51 AM mariappan balraj <
mariappan.balraj@gmail.com> wrote:

> Hi Tom Tromey,
>
> Thanks for looking into this.
>
> Please find the steps:
> 1) Create a directory named TEST
> 2) In TEST create 2 GO files, test.go and export.go
>
> ===>test.go
>
> package main
>
> /*
> #include <stdio.h>
>
> extern void Test4(void);
>
> void test1(void) {
>    Test4();
> }
>
> void test2(void) {
>     int val = 2;
>     test1();
> }
>
> void test3(void) {
>     int val = 3;
>     test2();
> }
> */
> import "C"
>
> func main() {
>     C.test3()
> }
>
> ===>export.go
>
> package main
>
> import "C"
>
> //export Test4
> func Test4() {
>     panic("Panic inside Test4")
> }
>
> 3) Run "go mod init test"
> 4) Run "go mod tidy"
> 5) Run "go build ."
> 6) Run "sudo su"
> 7) Run "ulimit -c unlimited"
> 8) Run "echo "core" > /proc/sys/kernel/core_pattern"
> 9) Run "GOTRACEBACK=crash ./test"
> 10) Run "gdb ./test core.243539"
>
> Best Regards
> Mariappan
>
> On Tue, Jan 24, 2023 at 6:39 PM tromey at sourceware dot org <
> sourceware-bugzilla@sourceware.org> wrote:
>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>>
>> Tom Tromey <tromey at sourceware dot org> changed:
>>
>>            What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>                  CC|                            |tromey at sourceware dot
>> org
>>
>> --- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
>> Could you say how to compile this?
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>> You are on the CC list for the bug.
>
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
This seems to work for me:

(gdb) frame
#7  0x0000000000405040 in test1 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:9
9          Test4();

Also, from bt:

#5  0x000000000040475e in main.Test4 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/export.go:7
#6  0x00000000004047ac in main.Cgoexp__Test4 () at
/tmp/go-build/b001/_cgo_gotypes.go:34
#7  0x0000000000405040 in test1 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:9
#8  0x0000000000405060 in test2 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:14
#9  0x0000000000405080 in test3 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:19
#10 0x00000000004050a0 in _cgo_5bc4e3e20e89_Cfunc_test3 () at
/tmp/go-build/cgo-gcc-prolog:46
#11 0x0000000000404ed8 in main.__Cfunc__test3 () at
/tmp/go-build/b001/_cgo_gotypes.go:25


I tried this live, not a core file though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #6 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hi,

Things are fine when we do live debugging. I am more worried about core
dump debugging. Is it possible to make it work for core dump also?

Best Regards
Mariappan

On Tue, Feb 14, 2023 at 11:42 AM tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>
> --- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
> This seems to work for me:
>
> (gdb) frame
> #7  0x0000000000405040 in test1 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:9
> 9          Test4();
>
> Also, from bt:
>
> #5  0x000000000040475e in main.Test4 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/export.go:7
> #6  0x00000000004047ac in main.Cgoexp__Test4 () at
> /tmp/go-build/b001/_cgo_gotypes.go:34
> #7  0x0000000000405040 in test1 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:9
> #8  0x0000000000405060 in test2 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:14
> #9  0x0000000000405080 in test3 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:19
> #10 0x00000000004050a0 in _cgo_5bc4e3e20e89_Cfunc_test3 () at
> /tmp/go-build/cgo-gcc-prolog:46
> #11 0x0000000000404ed8 in main.__Cfunc__test3 () at
> /tmp/go-build/b001/_cgo_gotypes.go:25
>
>
> I tried this live, not a core file though.
>
> --
> You are receiving this mail because:
> You reported the bug.
> You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
This also works for me:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./test'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fcf8468ec0c in __pthread_kill_implementation () from
/lib64/libc.so.6
[Current thread is 1 (Thread 0x7fcf8667a1c0 (LWP 1993139))]
(gdb) bt
#0  0x00007fcf8468ec0c in __pthread_kill_implementation () from
/lib64/libc.so.6
#1  0x00007fcf8463e986 in raise () from /lib64/libc.so.6
#2  0x00007fcf85b2ae84 in runtime[dieFromSignal] () from /lib64/libgo.so.21
#3  0x00007fcf85b54f00 in runtime[sigtrampgo] () from /lib64/libgo.so.21
#4  0x00007fcf855f1bf8 in runtime[sigtramp] () from /lib64/libgo.so.21
#5  <signal handler called>
#6  0x00007fcf8468ec0c in __pthread_kill_implementation () from
/lib64/libc.so.6
#7  0x00007fcf8463e986 in raise () from /lib64/libc.so.6
#8  0x00007fcf85b2ae84 in runtime[dieFromSignal] () from /lib64/libgo.so.21
#9  0x00007fcf85b2aeee in runtime[crash] () from /lib64/libgo.so.21
#10 0x00007fcf85b5e405 in runtime[gopanic] () from /lib64/libgo.so.21
#11 0x000000000040475e in main.Test4 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/export.go:7
#12 0x00000000004047ac in main.Cgoexp__Test4 () at
/tmp/go-build/b001/_cgo_gotypes.go:34
#13 0x0000000000405040 in test1 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:9
#14 0x0000000000405060 in test2 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:14
#15 0x0000000000405080 in test3 () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:19
#16 0x00000000004050a0 in _cgo_5bc4e3e20e89_Cfunc_test3 () at
/tmp/go-build/cgo-gcc-prolog:46
#17 0x0000000000404ed8 in main.__Cfunc__test3 () at
/tmp/go-build/b001/_cgo_gotypes.go:25
#18 0x0000000000404f54 in main.main () at
/home/tromey/gdb/PRS/pr-30038-go-bug/test.go:25


I'm using the system 'go' on Fedora 36.
Perhaps it's some other issue in your environment.
It doesn't seem to be a gdb bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #8 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hi,

I am really happy with your continuous support on this issue. It is good
that it is working in Fedora 36. I am using UBUNTU for my testing. Is it
possible to check the behaviour in UBUNTU also? I was following this issue
with the official GO team also. They also said that it is the problem with
GDB. GDB works well in Fedora and not in UBUNTU also is a compatible issue
with GDB right?

https://github.com/golang/go/issues/57698

Best Regards
Mariappan

On Tue, Feb 14, 2023 at 1:24 PM tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>
> --- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
> This also works for me:
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `./test'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x00007fcf8468ec0c in __pthread_kill_implementation () from
> /lib64/libc.so.6
> [Current thread is 1 (Thread 0x7fcf8667a1c0 (LWP 1993139))]
> (gdb) bt
> #0  0x00007fcf8468ec0c in __pthread_kill_implementation () from
> /lib64/libc.so.6
> #1  0x00007fcf8463e986 in raise () from /lib64/libc.so.6
> #2  0x00007fcf85b2ae84 in runtime[dieFromSignal] () from /lib64/libgo.so.21
> #3  0x00007fcf85b54f00 in runtime[sigtrampgo] () from /lib64/libgo.so.21
> #4  0x00007fcf855f1bf8 in runtime[sigtramp] () from /lib64/libgo.so.21
> #5  <signal handler called>
> #6  0x00007fcf8468ec0c in __pthread_kill_implementation () from
> /lib64/libc.so.6
> #7  0x00007fcf8463e986 in raise () from /lib64/libc.so.6
> #8  0x00007fcf85b2ae84 in runtime[dieFromSignal] () from /lib64/libgo.so.21
> #9  0x00007fcf85b2aeee in runtime[crash] () from /lib64/libgo.so.21
> #10 0x00007fcf85b5e405 in runtime[gopanic] () from /lib64/libgo.so.21
> #11 0x000000000040475e in main.Test4 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/export.go:7
> #12 0x00000000004047ac in main.Cgoexp__Test4 () at
> /tmp/go-build/b001/_cgo_gotypes.go:34
> #13 0x0000000000405040 in test1 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:9
> #14 0x0000000000405060 in test2 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:14
> #15 0x0000000000405080 in test3 () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:19
> #16 0x00000000004050a0 in _cgo_5bc4e3e20e89_Cfunc_test3 () at
> /tmp/go-build/cgo-gcc-prolog:46
> #17 0x0000000000404ed8 in main.__Cfunc__test3 () at
> /tmp/go-build/b001/_cgo_gotypes.go:25
> #18 0x0000000000404f54 in main.main () at
> /home/tromey/gdb/PRS/pr-30038-go-bug/test.go:25
>
>
> I'm using the system 'go' on Fedora 36.
> Perhaps it's some other issue in your environment.
> It doesn't seem to be a gdb bug.
>
> --
> You are receiving this mail because:
> You reported the bug.
> You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
Sorry, I can't check on Ubuntu for you.
I think you will have to look more deeply into it yourself somehow.
Normally a core file shouldn't affect the backtrace.
So I suspect something is weird in your environment, like
maybe you compiled something with optimization or LTO or the like.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #10 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hi,

I am seeing the same behaviour even in red hat linux. It is good if you can
share your go environment and the steps you are following to build it. So
that I can try. If that solves the issue then it is really nice. Kindly
please help.

Best Regards
Mariappan

On Tue, Feb 14, 2023 at 11:09 PM tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>
> --- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
> Sorry, I can't check on Ubuntu for you.
> I think you will have to look more deeply into it yourself somehow.
> Normally a core file shouldn't affect the backtrace.
> So I suspect something is weird in your environment, like
> maybe you compiled something with optimization or LTO or the like.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #11 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hi,

I am seeing some difference between what BT you are getting in and what I
am getting. In your case, libgo.so got used. But in my case it is not. I am
trying to understand what makes this difference. Could you please share the
following information? This will help me to progress further.

1) GO version
2) Build steps?
3) output of go env command
4) Output of "go version -m <go_binary>"

#8  0x00007fcf85b2ae84 in runtime[dieFromSignal] () from /lib64/libgo.so.21
#9  0x00007fcf85b2aeee in runtime[crash] () from /lib64/libgo.so.21
#10 0x00007fcf85b5e405 in runtime[gopanic] () from /lib64/libgo.so.21

#8  0x00000000004411e5 in runtime.dieFromSignal (sig=6) at
/usr/lib/go-1.18/src/runtime/signal_unix.go:852
#9  0x000000000042dca9 in runtime.crash () at
/usr/lib/go-1.18/src/runtime/signal_unix.go:944
#10 runtime.fatalpanic (msgs=<optimized out>) at
/usr/lib/go-1.18/src/runtime/panic.go:1092
#11 0x000000000042d477 in runtime.gopanic (e=...) at
/usr/lib/go-1.18/src/runtime/panic.go:941

Best Regards
Mariappan

On Wed, Feb 15, 2023 at 11:24 AM mariappan balraj <
mariappan.balraj@gmail.com> wrote:

> Hi,
>
> I am seeing the same behaviour even in red hat linux. It is good if you
> can share your go environment and the steps you are following to build it.
> So that I can try. If that solves the issue then it is really nice. Kindly
> please help.
>
> Best Regards
> Mariappan
>
> On Tue, Feb 14, 2023 at 11:09 PM tromey at sourceware dot org <
> sourceware-bugzilla@sourceware.org> wrote:
>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>>
>> --- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
>> Sorry, I can't check on Ubuntu for you.
>> I think you will have to look more deeply into it yourself somehow.
>> Normally a core file shouldn't affect the backtrace.
>> So I suspect something is weird in your environment, like
>> maybe you compiled something with optimization or LTO or the like.
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>> You reported the bug.
>
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #12 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to mariappan balraj from comment #11)
> Created attachment 14686 [details]
> attachment-2197679-0.html
> 
> Hi,
> 
> I am seeing some difference between what BT you are getting in and what I
> am getting. In your case, libgo.so got used. But in my case it is not. I am
> trying to understand what makes this difference. Could you please share the
> following information? This will help me to progress further.
> 
> 1) GO version
> 2) Build steps?
> 3) output of go env command
> 4) Output of "go version -m <go_binary>"

I'll try to get this later, but for the build steps I just did
exactly what you wrote in comment #2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[ian at airs dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #13 from Ian Lance Taylor <ian at airs dot com> ---
Hi Tom, based on your backtrace, you are using gccgo.  I think that the OP is
using the gc compiler.  Both provide a "go" program that works the same way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #14 from Tom Tromey <tromey at sourceware dot org> ---
Thanks Ian.

Looking into it a little bit, I think these functions are just
being optimized out:

(gdb) down 
#19 0x00000000004041a5 in runtime.cgocall (fn=0x4582e0
<_cgo_5bc4e3e20e89_Cfunc_test3>, arg=0xc00005af70, ~r0=<optimized out>)
    at /usr/lib/golang/src/runtime/cgocall.go:167
167             errno := asmcgocall(fn, arg)
(gdb) p fn
$1 = (void *) 0x4582e0 <_cgo_5bc4e3e20e89_Cfunc_test3>


Let's look at that:

(gdb) disassemble 0x4582e0
Dump of assembler code for function _cgo_5bc4e3e20e89_Cfunc_test3:
   0x00000000004582e0 <+0>:     jmp    0x4582d0 <test3>
End of assembler dump.


That jumps to:

(gdb) disassemble 0x4582d0
Dump of assembler code for function test3:
   0x00000000004582d0 <+0>:     jmp    0x4582c0 <test2>
End of assembler dump.


So, looks like tail calls to me.

I do see this frame:

#20 0x00000000004581e5 in main._Cfunc_test3 (r1=...) at _cgo_gotypes.go:41

which I feel proves that C functions can show up in the bt.

Just to be really clear here, I know nothing about go and even less
about non-gcc go.  This code in gdb is essentially unmaintained.
I don't even know if it was written to assume gccgo or golang-go.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #15 from mariappan balraj <mariappan.balraj at gmail dot com> ---
Hi Tromey,

Ian mentioned that "gccgo is not as well supported as the gc compiler".
https://github.com/golang/go/issues/57698

Is it possible to provide support from GDB to decode BT when the Go
compiler is used? If you can give guidance and direction then it may be
possible for me to contribute? Eagerly waiting for your strong support to
resolve this issue.

Go compiler(GC) can be invoked by using build option -compiler gc.
Optimization and inlining can be disabled by using the following command.

CGO_CFLAGS="-g" go build -compiler gc -gcflags=all="-N -l" .

Best Regards
Mariappan

On Fri, Feb 17, 2023 at 6:51 AM tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=30038
>
> --- Comment #14 from Tom Tromey <tromey at sourceware dot org> ---
> Thanks Ian.
>
> Looking into it a little bit, I think these functions are just
> being optimized out:
>
> (gdb) down
> #19 0x00000000004041a5 in runtime.cgocall (fn=0x4582e0
> <_cgo_5bc4e3e20e89_Cfunc_test3>, arg=0xc00005af70, ~r0=<optimized out>)
>     at /usr/lib/golang/src/runtime/cgocall.go:167
> 167             errno := asmcgocall(fn, arg)
> (gdb) p fn
> $1 = (void *) 0x4582e0 <_cgo_5bc4e3e20e89_Cfunc_test3>
>
>
> Let's look at that:
>
> (gdb) disassemble 0x4582e0
> Dump of assembler code for function _cgo_5bc4e3e20e89_Cfunc_test3:
>    0x00000000004582e0 <+0>:     jmp    0x4582d0 <test3>
> End of assembler dump.
>
>
> That jumps to:
>
> (gdb) disassemble 0x4582d0
> Dump of assembler code for function test3:
>    0x00000000004582d0 <+0>:     jmp    0x4582c0 <test2>
> End of assembler dump.
>
>
> So, looks like tail calls to me.
>
> I do see this frame:
>
> #20 0x00000000004581e5 in main._Cfunc_test3 (r1=...) at _cgo_gotypes.go:41
>
> which I feel proves that C functions can show up in the bt.
>
> Just to be really clear here, I know nothing about go and even less
> about non-gcc go.  This code in gdb is essentially unmaintained.
> I don't even know if it was written to assume gccgo or golang-go.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #16 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to mariappan balraj from comment #15)

> Is it possible to provide support from GDB to decode BT when the Go
> compiler is used? If you can give guidance and direction then it may be
> possible for me to contribute? Eagerly waiting for your strong support to
> resolve this issue.

Sorry about the delay.

I welcome any improvements you might care to make to the Go support.
There is some info on the wiki about writing patches and submitting
them.

However, in this particular case, it seems to me that gdb is doing
about as well as possible given the information it has.

But, it might be worthwhile for you to investigate and see if there
is something missing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[mariappan.balraj at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30038

--- Comment #17 from mariappan balraj <mariappan.balraj at gmail dot com> ---
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 functions
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 called.
When the C function is called, the stack is switched to system stack. In this
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 <stdio.h>

void test1(void) {
    printf("Welcome");
}

void test2(void) {
    int val = 2;
    test1();
}

void test3(void) {
    int val = 3;
    test2();
}
*/
import "C"

func test5() {
    C.test3()
}

func test4() {
    test5()
}

func main() {
    test4()
}

Command used to build:

CGO_CFLAGS="-g" go build -compiler gc -gcflags=all="-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 
[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, line 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=0xc000048f50) 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=0x1) at <autogenerated>: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=0xc000048f50) 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 
0xc000048f40:   0x00048f50      0x000000c0      0x00464297      0x00000000

(gdb) disassemble 0x00464297
Dump of assembler code for function main.test5:

(gdb) x /4 0x000000c000048f50 
0xc000048f50:   0x00048f60      0x000000c0      0x004642d7      0x00000000

(gdb) disassemble 0x004642d7
Dump of assembler code for function main.test4:

(gdb) x /4 0x000000c000048f60 
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.