This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.3 problem of -fzero-initialized-in-bss w/-ffreestanding
- From: neroden at twcny dot rr dot com (Nathanael Nerode)
- To: gcc at gcc dot gnu dot org
- Date: Tue, 15 Jul 2003 01:28:24 -0400
- Subject: Re: 3.3 problem of -fzero-initialized-in-bss w/-ffreestanding
>> No, this broke Emacs on SPARC/Solaris (and on other platforms I
>suspect). The
>> Emacs folks have already patched their CVS tree, but this option
>shouldn't
>> have made its way into GCC 3.3 in the first place because Emacs is
>supposed
>> to be part of the release criteria.
>
>How does it break Emacs - and what's the workaround?
It wasn't a GCC bug. Emacs has a demented thing in its build
process where it loads a bunch of stuff into memory and then tries to
create an executable from the memory image. As part of this, it assumed
various things about memory layout which just happened to be true
before, and are no longer true with GCC 3.3. The fix was to fix emacs
to stop assuming some things which aren't true :-), and to use kludges
to force some of the memory layout into the way it wants it.
I disagree that it should never have gotten into GCC 3.3; emacs has no
right to make random assumptions about memory layout, and should expect
to break regularly with new versions of GCC as long as it has such
assumptions. As long as 'temacs' (emacs before the
create-executable-from-memory-image stuff) works perfectly, I think
we're doing our job. As a matter of fact, the emacs manual documents
that the create-executable-from-memory-image stuff may not work, and
explains how to use temacs directly.
--
Nathanael Nerode <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html