On Tue, Jan 23, 2018 at 5:49 AM, Ian Lance Taylor <i...@golang.org> wrote: > On Sun, Jan 21, 2018 at 3:13 PM, Uros Bizjak <ubiz...@gmail.com> wrote: >> >> The default "go build" compile options over-optimize the auxiliary >> executable, built in TestCrashDumpsAllThreads testcase >> (libgo/go/runtime/crash_unix_test.go). This over-optimization results >> in removal of the trivial summing loop and in the inlining of the >> main.loop function into main.$thunk0. >> >> The testcase expects backtrace that shows several instances of >> main.loop in the backtrace dump. When main.loop gets inlined into >> thunk, its name is not dumped anymore. >> >> The solution is to pass "-O0" to gccgo, which inhibits unwanted inlining. >> >> Patch was bootstrapped and regression tested on x86_64-linux-gnu and >> alphev68-linux-gnu, where for the later target the patch fixed the >> mentioned failure. > > That sounds like a bug somewhere. Even when one function gets inlined > into another, its name should still be dumped. This is implemented by > report_inlined_functions in libbacktrace/dwarf.c. While something > like your patch may be needed, I'd like to more clearly understand why > libbacktrace isn't working.
If I manually compile the testcase from crash_unix_test.go wth gccgo -O2 (the asm is attached), the main.loop function is not even present in the dump. Even gdb session shows: (gdb) b main.loop Breakpoint 1 at 0x1200021f8: file main.go, line 11. (gdb) r Starting program: /space/homedirs/uros/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0x200028831e0 (LWP 23072)] [New Thread 0x2000308b1e0 (LWP 23073)] [New Thread 0x20003c931e0 (LWP 23074)] [New Thread 0x20008fff1e0 (LWP 23075)] [New Thread 0x2000a7ff1e0 (LWP 23076)] [Switching to Thread 0x20003c931e0 (LWP 23074)] Thread 4 "a.out" hit Breakpoint 1, main.$thunk0 () at main.go:25 25 go loop(i, chans[i]) (gdb) bt #0 main.$thunk0 () at main.go:25 #1 0x000002000100bf54 in runtime.kickoff () at /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/proc.go:1161 #2 0x0000020001a4f934 in ?? () from /lib/libc.so.6.1 While it is possible to put breakpoint at main.loop, the gdb backtrace omits function name and displays only thunk. When -O0 is used, the gdb backtrace shows: (gdb) bt #0 main.loop () at main.go:11 #1 0x000000012000237c in main.$thunk0 () at main.go:25 #2 0x000002000100bf54 in runtime.kickoff () at /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/proc.go:1161 #3 0x0000020001a4f934 in ?? () from /lib/libc.so.6.1 I don't think this is a bug in libbacktrace, the function simply isn't there. Uros.
main.s.gz
Description: GNU Zip compressed data
