https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116642
--- Comment #26 from Joshua <joshudson at gmail dot com> ---
I've been wondering how to fix this item. Having found the faulting assembly
code; vfork is incidental to the problem. Removing vfork simply preterbs it
away not actually fixing.
I actually hit this once before with execve but without vfork; failed to find
the actual problem, and use memcpy to build up the array in a buffer rather
than the inline initializer to get rid of it.
What this code *is* is the root component of a 20,000 line web management
interface. It's still growing; the final target looks like it's going to be
50,000 lines with 1,200 lines of root code.
Everything it doesn't need has been stripped away. libc is gone, replaced with
three hundred lines of assembly mostly declaring system calls. The dynamic
linker is gone; one less piece of code to audit.
So the root failing construct is:
.LC16:
.quad .LC7
You can't *do* that in this environment. No relocations allowed.
The sse code that is using it is a pessimization not an optimization anyway. To
avoid a register stall it wants a relocation and a memory access. That
relocation costs more than the register stall.
So ultimately the best way to fix it is to stop generating that construct and
similar constructs; as though this were the the ELF relocation processor
itself. If -mno-sse is what it takes, that's fine. But I need to know exactly
how it's intended to be done. Adding more compiler options costs me nothing.
Adding more compiler options blindly hoping I've got the right ones costs too
much.
So far I haven't gotten a new upstream gcc; I could if it fixed the problem.
It's just a build management problem that I'm not going to tackle unless I need
to.
