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: 11 Jul 2003 09:46:12 -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-11 09:46 -------
Hi, finally, I obtained the objdump output of temacs and bootstrap-emacs.
Here is a recap of Problems with gcc 3.3
On UltraSparc Solaris 8,
gcc 3.3 creates a bootstrap-emacs (from temacs)
that crashes upon exit.
gcc 3.2.3 didn't have such problem.
gcc 3.2.3 version:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.3/specs
Configured with: ../configure --disable-nls --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.2.3
gcc 3.3 version:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/specs
Configured with: /home/ishikawa/PACKAGES/gcc-3.3-cvs/gcc/configure
--enable-languages=c --program-suffix=-3.3-branch
Thread model: posix
gcc version 3.3.1 20030703 (prerelease)
This is the analysis by looking at the
created binary's ELF headers using
objdump -x
(I compiled objdump by downloading binutils myself.
But I didn't install binutils package as a whole.
I am using Sun's as and ld.)
Also, please bear in mind that temacs is the
natively produced executable and
then it subsequently deforms itself into another executable
by callilng unexec() in emacs-21.3/src/unexelf.c.
temacs -- through unexec() --> bootstrap-emacs
bootstrap-emacs is created with the following shell script.
Before bootstrap-emacs is created, a program "temacs" has
been compiled and linked using GCC.
cd emacs-21.3/src
./temacs --batch --load loadup bootstrap
# the above creates a new executable by unexec()/dumping
# called 'emacs' and then it is renamed bootstrap-emacs
#
mv -f emacs bootstrap-emacs
mv temacs bootstrap-temacs-saved
rm -f temacs
Attached Listing
[1] objdump -x output for temacs compiled by GCC 3.2.3
[2] objdump -x output for emacs with GCC 3.2.3
[3] objdump -x output for bootstrap-emacs with GCC 3.2.3
[4] diff of [1] and [2]
[5] objdump -x output for temacs compiled by GCC 3.3-branch
[6] objdump -x output for bootstrap-emacs with GCC 3.3-branch
(Since bootstrap-emacs aborts, I could not produce
emacs.)
[7] diff of [2] and [5]
[8] diff of [3] and [6]
Observation:
I immediately noticed that comparing the bootstrap-emacs
objdump output ([8]) that
bootstrap-emacs didn't have D_PAGE architecture flag disabled
with GCC 3.3-branch whereas (unexeced/dumped) bootstrap-emacs under
gcc 3.2.3 still has D_PAGE attribute.
I wonder if this is the culprit.
(But I have no idea how this came about.)
---- Quote of the relevant diff output: Quote from [8]
*** /tmp/working-b.lst 2003 July 11 Fri
--- /tmp/b.lst 2003 July 11 Fri
***************
*** 1,9 ****
! src/bootstrap-emacs: file format elf32-sparc
! src/bootstrap-emacs
! architecture: sparc, flags 0x00000112:
! EXEC_P, HAS_SYMS, D_PAGED
! start address 0x00041d30
Program Header:
PHDR off 0x00000034 vaddr 0x00010034 paddr 0x00000000 align 2**0
--- 1,9 ----
! bootstrap-emacs: file format elf32-sparc
! bootstrap-emacs
! architecture: sparc, flags 0x00000012:
! EXEC_P, HAS_SYMS
! start address 0x00041d0c
Program Header:
PHDR off 0x00000034 vaddr 0x00010034 paddr 0x00000000 align 2**0
***************
*** 11,20 ****
INTERP off 0x000000d4 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000011 memsz 0x00000000 flags r--
LOAD off 0x00000000 vaddr 0x00010000 paddr 0x00000000 align 2**16
! filesz 0x00193f70 memsz 0x00193f70 flags r-x
! LOAD off 0x00193f70 vaddr 0x001b3f70 paddr 0x00000000 align 2**16
! filesz 0x00344090 memsz 0x00344090 flags rwx
! DYNAMIC off 0x00195264 vaddr 0x001b5264 paddr 0x00000000 align 2**0
filesz 0x00000128 memsz 0x00000000 flags rwx
Dynamic Section:
--- 11,20 ----
INTERP off 0x000000d4 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000011 memsz 0x00000000 flags r--
LOAD off 0x00000000 vaddr 0x00010000 paddr 0x00000000 align 2**16
! filesz 0x002c0a30 memsz 0x002c0a30 flags r-x
! LOAD off 0x002c0a30 vaddr 0x002e0a30 paddr 0x00000000 align 2**16
! filesz 0x0079d5d0 memsz 0x0079d5d0 flags rwx
! DYNAMIC off 0x002c1d18 vaddr 0x002e1d18 paddr 0x00000000 align 2**0
filesz 0x00000128 memsz 0x00000000 flags rwx
---- end quote
As a general observation,
for dumped/unexeced images under both GCC versons,
we get new "data" section between
data.rel.local and .bss section. This was not
in the original temacs. But this only reflects
the nature of data undumping done by unexec().
I attach the whole file as zipped attachment for
people's information.
Again any insight and suggestion for further debugging
steps welcome.
Listing attached in the next posting.