Hi Iain,
>> unfortunately, Solaris/SPARC results are miserable:
>>
>> * About 1600 Go tests FAIL, spread across go.*, libgo, and gotools, all
>> in the same way, it seems:
>>
>> +FAIL: go.go-torture/execute/array-1.go execution, -O0
>>
>> fatal error: DWARF underflow in .debug_line at 3266879
>>
>> goroutine 1 [running, locked to thread]:
>> fatal error: DWARF underflow in .debug_line at 3266879
>> panic during panic
>>
>> goroutine 1 [running, locked to thread]:
>> fatal error: DWARF underflow in .debug_line at 3266879
>> stack trace unavailable
>
> go is stil not implemented for Darwin, so I have no comparison there.
I suspect this is not about Go in particular, but about a buggy
assembler ;-) The Solaris as track record isn't really the best,
unfortunately.
I just had a quick look at the stacktrace at the failure point
Thread 2 hit Breakpoint 1, 0xfeb60cc8 in runtime.throw (s=...) at
/vol/gcc/src/hg/master/local/libgo/go/runtime/internal/sys/intrinsics_common.go:33837
33837
/vol/gcc/src/hg/master/local/libgo/go/runtime/internal/sys/intrinsics_common.go:
No such file or directory.
(gdb) where
#0 0xfeb60cc8 in runtime.throw (s=...) at
/vol/gcc/src/hg/master/local/libgo/go/runtime/internal/sys/intrinsics_common.go:33837
#1 0xfe6a1c0c in runtime_throw (s=0x64d100 "DWARF underflow in .debug_line at
3266879") at /vol/gcc/src/hg/master/local/libgo/runtime/panic.c:13
#2 0xfe69ea18 in error_callback (data=0x64d9e0, errnum=0, msg=0x64d100 "DWARF
underflow in .debug_line at 3266879") at
/vol/gcc/src/hg/master/local/libgo/runtime/go-callers.c:68
#3 error_callback (data=0x64d9e0, msg=0x64d100 "DWARF underflow in .debug_line
at 3266879", errnum=0) at
/vol/gcc/src/hg/master/local/libgo/runtime/go-callers.c:211
#4 0xfecd22d0 in dwarf_buf_error (msg=<optimized out>, buf=<optimized out>) at
/vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:16103
#5 require (count=<optimized out>, buf=<optimized out>) at
/vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:433
#6 advance (count=<optimized out>, buf=<optimized out>) at
/vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:446
#7 read_line_program (vec=<optimized out>, line_buf=<optimized out>,
hdr=<optimized out>, u=<optimized out>, ddata=<optimized out>, state=<optimized
out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:2819
#8 read_line_info (lines_count=<synthetic pointer>, lines=<synthetic pointer>,
hdr=<error reading variable: DWARF expression error: ran off end of buffer
reading sleb128 value>, u=<optimized out>, data=<optimized out>,
error_callback=<optimized out>, ddata=0xed188510, state=0xff188000) at
/vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:2951
#9 dwarf_lookup_pc (state=0xff188000, ddata=0xed188510, pc=<optimized out>,
callback=<optimized out>, error_callback=<optimized out>, data=<optimized out>,
found=<optimized out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:3732
#10 0xfecd3300 in dwarf_fileline (state=0xff188000, pc=4273447611,
callback=0xfe69ec04 <callback>, error_callback=0xfe69e9e4 <error_callback>,
data=0x64d9e0) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:20031
#11 0xfecd4160 in backtrace_pcinfo (state=0xff188000, pc=4273447611,
callback=0xfe69ec04 <callback>, error_callback=0xfe69e9e4 <error_callback>,
data=0x64d9e0) at /vol/gcc/src/hg/master/local/libbacktrace/fileline.c:973
#12 0xfecd4714 in unwind (context=<optimized out>, vdata=0x64d964) at
/vol/gcc/src/hg/master/local/libbacktrace/backtrace.c:91
#13 0xff13c8d4 in _Unwind_Backtrace (trace=0xfecd4688 <unwind>,
trace_argument=0x64d964) at
/builds2/ulhg/nightly_85/components/gcc10/gcc-10.2.0/libgcc/unwind.inc:307
#14 0xfecd479c in backtrace_full (state=0xff188000, skip=0, callback=0xfe69ec04
<callback>, error_callback=0xfe69e9e4 <error_callback>, data=0x64d9e0) at
/vol/gcc/src/hg/master/local/libbacktrace/backtrace.c:127
[...]
which shows that the problem is detected in the depths of
libbacktrace's DWARF reader. There's something completely off in
places, like line numbers well beyond the end of dwarf.c.
TBH, I don't really feel like diving into the innards of libbacktrace
and DWARF at this point to investigate.
>> All this happens for both 32 and 64-bit tests.
>>
>> To ascertain that this is really the leb128 patch, I've reverted it in
>> my tree and reran the bootstrap: all those failures are gone.
>>
>> So without further investigation, we cannot use the leb128 directives
>> with Solaris/SPARC as.
>
> I think Andrew was running GCN (not sure of the results there)
>
> - but, I suppose that the simplest modification is to do
>
> elif … target is darwin
>
> and make it so that other (non-GNU-as) platforms have to opt in.
Agreed: that's certainly the safest option given that we're in stage3.
While it would be nice to be able to use the leb128 directives, I
wouldn't consider this crucial.
> I’ll make a version that does this and test it locally.
Great, thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
