This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/11386] GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works.
- From: "ishikawa at yk dot rim dot or dot jp" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Jul 2003 23:25:04 -0000
- Subject: [Bug optimization/11386] GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works.
- References: <20030630221211.11386.ishikawa@yk.rim.or.jp>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386
------- Additional Comments From ishikawa at yk dot rim dot or dot jp 2003-07-07 23:25 -------
As Simon Marshall in message # 11 shows that "-g -O" results in
the same segmentation error problem as I have observed.
(I wrote a script to re-compile files one by one, but
it would take a couple of days. His work saved me an extra work.)
So I am more inclined to believe it is the startup code layout problem or
something. I checked with gnu.emacs.help (I should have used gnu.emacs.bugs
where developer are more like to hang around)
and was suggested to use objdump to look inside the
generated code.
So my current plan is to look at using objdump the current files:
temacs <- natively linked generated emacs executable.
bootstrap-emacs <- This is an image created from
temacs by dump/unexecin after reading some data (emacs
lisp code.)
I suspect that the unexec code in emacs-21.3/src/unexelf.c
probably misbehaves due to the
very subtle memory layout in temacs generated by GCC 3.3.
Probably I should be able to find a difference between
temacs (by GCC 3.2.3) objdump segment listing and
temacs (by GCC 3.3) objdump segment listing.
bootstrap-emacs (by GCC 3.2.3), and
bootstrap-emacs (by GCC 3.3).
If worst comes to worst, I am planning to insert a few write() calls
inside crtstuff.c to print out the __DTOR___, etc inside
the C startup/epilogue function in order to find out what is going on
there.
The function __do_global_dtor_aux() can't (shouldn't) fail if these
global values are set up correctly, right?
So something screws up the initialization, etc..
Failing inside __do_global_dtor_aux() is exactly what I have observed myself
in the local gdb sessions.
Suggestion welcome.