Re: [PATCH, gotools]: Fix TestCrashDumpsAllThreads testcase failure

[Uros Bizjak <ubizjak at gmail dot com>]

On Tue, Jan 23, 2018 at 5:49 AM, Ian Lance Taylor <iant@golang.org> wrote:
> On Sun, Jan 21, 2018 at 3:13 PM, Uros Bizjak <ubizjak@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.

Attachment: main.s.gz
Description: GNU Zip compressed data