On Tue, Jan 23, 2018 at 8:32 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> 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.
Digging deeper into the source, here is the problem:
When inlined, the thunk reads:
0000000000000260 <main.$thunk0>:
260: 00 00 bb 27 ldah gp,0(t12)
260: GPDISP .text+0x4
264: 00 00 bd 23 lda gp,0(gp)
268: 08 00 10 a6 ldq a0,8(a0)
26c: 00 00 7d a7 ldq t12,0(gp)
26c: ELF_LITERAL runtime.closechan
270: f0 ff de 23 lda sp,-16(sp)
274: 00 00 5e b7 stq ra,0(sp)
278: 00 40 5b 6b jsr ra,(t12),27c <main.$thunk0+0x1c>
278: LITUSE .text+0x3
278: HINT runtime.closechan
27c: 00 80 5f 24 ldah t1,-32768
280: 01 05 e2 47 not t1,t0
284: 00 00 fe 2f unop
288: 1f 04 ff 47 nop
28c: 00 00 fe 2f unop
290: ff ff 21 20 lda t0,-1(t0)
294: fe ff 3f f4 bne t0,290 <main.$thunk0+0x30>
298: 01 05 e2 47 not t1,t0
29c: fc ff ff c3 br 290 <main.$thunk0+0x30>
and the (very tight) loop consists only of insns at 0x290 and 0x294.
However, the assembly dump of the loop reads:
$L23:
lda $1,-1($1)
$LBB53:
$LBB51:
$LBB49:
$LBB47:
.loc 1 13 31
bne $1,$L23
$LBE47:
$LBE49:
$LBE51:
$LBE53:
with
$Ldebug_ranges0:
.8byte $LBB45-$Ltext0
.8byte $LBE45-$Ltext0
.8byte $LBB50-$Ltext0
.8byte $LBE50-$Ltext0
.8byte $LBB51-$Ltext0
.8byte $LBE51-$Ltext0
.8byte 0
.8byte 0
So, those $LBB labels are at the wrong place. During runtime, we get
(oh, why can't we display PC in hex?!):
SIGQUIT: quit
PC=4831845072 m=0 sigcode=0
goroutine 7 [running]:
runtime.sighandler
/space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/signal_sighandler.go:104
runtime.sigtrampgo
/space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/signal_unix.go:312
runtime.sigtramp
/space/homedirs/uros/gcc-svn/trunk/libgo/runtime/go-signal.c:54
runtime.kickoff
/space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/proc.go:1161
0x120001ad0
0000000120001aa0 <main.$thunk0>:
120001aa0: 02 00 bb 27 ldah gp,2(t12)
120001aa4: f0 a5 bd 23 lda gp,-23056(gp)
120001aa8: 08 00 10 a6 ldq a0,8(a0)
120001aac: c8 80 7d a7 ldq t12,-32568(gp)
120001ab0: f0 ff de 23 lda sp,-16(sp)
120001ab4: 00 00 5e b7 stq ra,0(sp)
120001ab8: 00 40 5b 6b jsr ra,(t12),120001abc <main.$thunk0+0x1c>
120001abc: 00 80 5f 24 ldah t1,-32768
120001ac0: 01 05 e2 47 not t1,t0
120001ac4: 00 00 fe 2f unop
120001ac8: 1f 04 ff 47 nop
120001acc: 00 00 fe 2f unop
> 120001ad0: ff ff 21 20 lda t0,-1(t0)
120001ad4: fe ff 3f f4 bne t0,120001ad0 <main.$thunk0+0x30>
120001ad8: 01 05 e2 47 not t1,t0
120001adc: fc ff ff c3 br 120001ad0 <main.$thunk0+0x30>
which is obviously out of corresponding debug range.
Contents of the .debug_ranges section:
Offset Begin End
00000000 0000000120001a7c 0000000120001a8c
00000000 0000000120001a90 0000000120001a9c
00000000 <End of list>
00000000 0000000120001a7c 0000000120001a8c
00000000 0000000120001a90 0000000120001a9c
00000000 <End of list>
00000030 0000000120001aa8 0000000120001ab0
00000030 0000000120001ab8 0000000120001abc
00000030 0000000120001ad4 0000000120001ad8 <<< this one!
00000030 <End of list>
Uros.
