On Fri, Feb 2, 2018 at 10:24 AM, Rainer Orth
<r...@cebitec.uni-bielefeld.de> wrote:
>
>>> the new test FAILs on Solaris 10, sparc and x86 (only, 11 is fine) at
>>> all optimization levels:
>>>
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O0
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O1
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O2
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O2 -fbounds-check
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O2
>>> -fomit-frame-pointer -finline-functions
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O2
>>> -fomit-frame-pointer -finline-functions -funroll-loops
>>> +FAIL: go.go-torture/execute/printnil.go execution, -O3 -g
>>> +FAIL: go.go-torture/execute/printnil.go execution, -Os
> [...]
>> It's normal for that panic to occur. That's not the point of failure.
>> The panic should be caught by the recover call in catchPanic
>> (libgo/go/fmt/print.go line 531). Does that code get executed? What
>> happens after that?
>
> thanks, that got pointed me in the right direction. I found that the
> callers() call in in go/runtime/callers.go (canrecover) differs between
> S10 and S11:
>
> * On Solaris 11, I get
>
> $7 = {pc = 4256946426,
> filename = 0xfc9bea08 "/vol/gcc/src/hg/trunk/local/libgo/go/fmt/print.go",
> function = 0xfb86337e "fmt.pp.catchPanic", lineno = 530}
>
> * while on Solaris 10 there's only
>
> $10 = {pc = 4267047674, filename = 0x0 "", function = 0x0 "", lineno = 0}
>
> The DWARF2 debug info for that function differs between the two:
>
> * Solaris 11:
>
> <1><17d6a5>: Abbrev Number: 24 (DW_TAG_subprogram)
> <17d6a6> DW_AT_external : 1
> <17d6a6> DW_AT_name : fmt.catchPanic..1fmt.pp
> <17d6be> DW_AT_decl_file : 2
> <17d6bf> DW_AT_decl_line : 530
> <17d6c1> DW_AT_decl_column : 1
> <17d6c2> DW_AT_linkage_name: fmt.pp.catchPanic
> <17d6d4> DW_AT_low_pc : 0x9bd8e0
> <17d6d8> DW_AT_high_pc : 0x36
> <17d6dc> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <17d6de> DW_AT_GNU_all_call_sites: 1
> <17d6de> DW_AT_sibling : <0x17d730>
>
> * Solaris 10:
>
> <1><192db2>: Abbrev Number: 24 (DW_TAG_subprogram)
> <192db3> DW_AT_external : 1
> <192db4> DW_AT_name : fmt.catchPanic..1fmt.pp
> <192dcc> DW_AT_decl_file : 2
> <192dcd> DW_AT_decl_line : 530
> <192dcf> DW_AT_decl_column : 1
> <192dd0> DW_AT_MIPS_linkage_name: fmt.pp.catchPanic
> <192de2> DW_AT_low_pc : 0x75fae0
> <192de6> DW_AT_high_pc : 0x75fb16
> <192dea> DW_AT_frame_base : 0x1303af (location list)
> <192dee> DW_AT_GNU_all_call_sites: 1
> <192def> DW_AT_sibling : <0x192e41>
>
> The Solaris 10 ld cannot support DWARF4, so it falls back to DWARF2,
> leading to DW_AT_MIPS_linkage_name instead of DW_AT_linkage_name.
>
> I've not yet digged further from here, but maybe that's already enough
> to get to the root cause.
Unfortunately not. The missing results in canrecover definitely look
bad. But this is coming from libbacktrace, and libbacktrace treats
DW_AT_linkage_name and DW_AT_MIPS_linkage_name exactly the same.
I note that the PC values above do not match the PC values in the
debug info. I have no explanation for that.
Ian
