This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Jan 23, 2018 at 11:38 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Tue, Jan 23, 2018 at 8:32 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> 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.
>
> Digging deeper into the source, here is the problem:

[...]

> So, those $LBB labels are at the wrong place. During runtime, we get
> (oh, why can't we display PC in hex?!):

Following testcase:

--cut here--
package main

func loop(i int, c chan bool) {
        close(c)
        for {
                for j := 0; j < 0x7fffffff; j++ {
                }
        }
}
--cut here--

can be compiled with a crosscompiler to alpha-linux-gnu:

~/gcc-build-alpha/gcc/go1 -O2 -fkeep-static-functions l.go

to generate assembly, where $LBB2 is placed after "lda" insn.

main.loop:
...
$L2:
        lda $1,-1($1)
$LBB2:
$LM6:
        bne $1,$L2
        br $31,$L3
$LBE2:
...

and in ._final, we can see that (note 52) is in wrong place. It should
be placed in front of (insn 13).

(code_label 14 6 12 2 (nil) [1 uses])
(note 12 14 13 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn:TI 13 12 52 (set (reg:DI 1 $1 [orig:70 ivtmp_1 ] [70])
        (plus:DI (reg:DI 1 $1 [orig:70 ivtmp_1 ] [70])
            (const_int -1 [0xffffffffffffffff]))) 7 {*adddi_internal}
     (nil))
(note 52 13 15 0x7f6b5f2791e0 NOTE_INSN_BLOCK_BEG)
(jump_insn:TI 15 52 45 (set (pc)
        (if_then_else (ne (reg:DI 1 $1 [orig:70 ivtmp_1 ] [70])
                (const_int 0 [0]))
            (label_ref:DI 14)
            (pc))) "l.go":6 169 {*bcc_normal}
     (int_list:REG_BR_PROB 1062895956 (nil))
 -> 14)
(note 45 15 46 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 46 45 47 (set (pc)
        (label_ref 16)) 200 {jump}
     (nil)
 -> 16)
(barrier 47 46 32)
(note 32 47 54 NOTE_INSN_DELETED)
(note 54 32 0 0x7f6b5f2791e0 NOTE_INSN_BLOCK_END)

I will open a PR:

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]