This is the mail archive of the gcc-bugs@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]

[Bug optimization/11386] GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works.


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.


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