https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
Bug ID: 87589
Summary: [8/9 regression] index0-out.go FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
The Go index0-out.go FAILs on mainline and the gcc-8 branch on many different
targets (aarch64-suse-linux-gnu,
arm-unknown-linux-gnueabi, arm-unknown-linux-gnueabihf,
ia64-suse-linux-gnu, powerpc64-suse-linux-gnu, riscv64-suse-linux-gnu,
s390x-ibm-linux-gnu according to gcc-testresults postings), while it PASSed on
the gcc-7 branch.
The failure modes are various, however:
* On Solaris/x86 with /bin/as, I get
FAIL: ./index0-out.go compilation, -O0 -g -fno-var-tracking-assignments
where as complains
Input string too long, limit 10240
It turns out that the lines in question are of the form
.weak gcbits..baza{100000}ba
i.e. 100000 'a' characters in a row. Maybe the test can be modified to
accomodate this restriction?
* On Solaris/x86 with gas and Solaris/SPARC, the test FAILs to execute instead:
FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments
The test SEGVs. While gdb gets royally confused, dbx shows what's going on:
t@1 (l@1) signal SEGV (no mapping at the fault address) in __go_init_main at
0x81b700e
0x081b700e: __go_init_main+0x000c: call import [PLT] [ 0x80b04b0,
.-0x106b5e ]
(dbx) where
current thread: t@1
=>[1] __go_init_main(0x0, 0x8a41f8a, 0x0, 0x0, 0x0, 0x0), at 0x81b700e
[2] main(0x0, 0xfe10a7d8, 0x8a41ff8, 0xfdffcc09), at 0xfdfffb0f
[3] kickoff(0x8801080, 0x0, 0x0, 0x8800b00, 0x0, 0x0), at 0xfdffcc70
[4] resumecontext(), at 0xfd0bf3a3
__go_init_main extends the stack way beyond the default stacksize limit of
8 MB:
(gdb) x/7i __go_init_main
0x81b7002 <__go_init_main>: push %ebp
0x81b7003 <__go_init_main+1>: mov %esp,%ebp
0x81b7005 <__go_init_main+3>: push %edi
0x81b7006 <__go_init_main+4>: push %esi
0x81b7007 <__go_init_main+5>: push %ebx
0x81b7008 <__go_init_main+6>: sub $0x3d0b9c,%esp
=> 0x81b700e <__go_init_main+12>:
call 0x80b04b0 <internal_cpu..import@plt>
which breaks the next call. However, even with ulimit -s unlimited, the
problem
remains.
* Even on Linux/x86_64 (Fedora 27) which has SplitStacks support, the test
FAILs:
fatal error: unexpected signal during runtime execution
If the test depends on -fsplit-stack support, it should be marked as such.
