This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]