This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2
- To: egcs at cygnus dot com
- Subject: Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2
- From: Jim Meyering <meyering at ascend dot com>
- Date: 17 Aug 1998 01:02:43 -0500
- Cc: rms at gnu dot org, law at cygnus dot com
- References: <87ogvnvnxi.fsf@eng.ascend.com> <87sok3zs6t.fsf@eng.ascend.com> <199807161236.FAA19821@dm.cobaltmicro.com> <199807170658.XAA28181@dm.cobaltmicro.com> <874swgr36t.fsf@ascend.com> <199807171412.HAA05886@dm.cobaltmicro.com> <87pvf4pl6t.fsf@ascend.com>
I regret that I haven't had time to work on this.
However, I did just confirm that the problem still exists with
this snapshot of the 1.1 branch from yesterday:
Reading specs from /p/p/egcs-980815-08h49/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.53/specs
gcc version egcs-2.91.53 19980815 (gcc2 ss-980609 experimental)
I did try to build a few `cvs update -D DATE'-selected
versions of egcs, but none of them bootstrapped. What version
of CVS is running on Cygnus' egcs repository?
Jim Meyering <meyering@ascend.com> writes:
| "David S. Miller" <davem@dm.cobaltmicro.com> writes:
|
| | From: Jim Meyering <meyering@ascend.com>
| |
| | 414008 pure bytes used
| | ./emacs -q -batch -f list-load-path-shadows
| | make: *** [emacs] Segmentation Fault
| |
| | I'm pretty sure that whatever it is about egcs that provokes
| | this was introduced in the first two weeks of June. The 980531
| | snapshot compiled it fine, and the first time I noticed the problem
| | was about two weeks later.
| |
| | Thanks for the further datapoints.
| |
| | I am still convinced that something is going wrong with unexec when
| | compiled with egcs. The evidence in your crash indicates this to me.
| |
| | I ask for one further experiment if you don't mind. Can you try
| | compiling just unexelf.o with a working gcc, leave the rest the same
| | (compiled with egcs which causes the crashes) and tell me the results.
| |
| | Also, it would be very useful if you could take the crashing emacs
| | binary and run it under gdb, and look around for clues as to where it
| | is crashing. I would not be surprised if you find it crashed
| | somewhere in the middle of the solaris dynamic linker, or some place
| | similar.
|
| I compiled unexelf.c using gcc-2.7.2.2 (with which I can build
| a working emacs-20.2), and tried to rebuild. Still to no avail.
|
| $ gdb emacs
| DISPLAY = :0.0
| TERM = xterm
| Breakpoint 1 at 0x8071a90
| Breakpoint 2 at 0x80c2055: file xterm.c, line 5241.
| (gdb) r -q -batch -f list-load-path-shadows
| Starting program: /d/pd/emacs/stable/emacs-20.2/src/emacs -q -batch -f list-load-
| path-shadows
| Breakpoint 1 at 0x801f57f0
|
| Program received signal SIGSEGV, Segmentation fault.
| 0x0 in ?? ()
| (gdb) w
| #0 0x0 in ?? ()
| #1 0x818ced4 in __do_global_ctors_aux ()
| #2 0x818cf15 in _init ()
|
| But it seems crtstuff.c (__do_global_ctors_aux) can't be
| compiled with -g, so here's some assembly.
|
| Breakpoint 3, 0x818cf00 in _init ()
| (gdb) disas 0x818cf00 0x818cf21
| Dump of assembler code from 0x818cf00 to 0x818cf4f:
| 0x818cf00 <_init>: call 0x807309c <frame_dummy>
| 0x818cf05 <_init+5>: leal 0x0(%esi,1),%esi
| 0x818cf09 <_init+9>: leal 0x0(%edi,1),%edi
| 0x818cf10 <_init+16>: call 0x818ceb0 <__do_global_ctors_aux>
| 0x818cf15 <_init+21>: leal 0x0(%esi,1),%esi
| 0x818cf19 <_init+25>: leal 0x0(%edi,1),%edi
| 0x818cf20 <_init+32>: ret $0x0
| End of assembler dump.
|
| stepping throught that, I made it into __register_frame_info
| and back to 0x818cf05. thence into __do_global_ctors_aux:
|
| 0x818cf10 in _init ()
| (gdb)
| 0x818ceb0 in __do_global_ctors_aux ()
| (gdb) disas 0x818ceb0 0x818cef0
| Dump of assembler code from 0x818ceb0 to 0x818cef0:
| 0x818ceb0 <__do_global_ctors_aux>: pushl %ebp
| 0x818ceb1 <__do_global_ctors_aux+1>: movl %esp,%ebp
| 0x818ceb3 <__do_global_ctors_aux+3>: pushl %esi
| 0x818ceb4 <__do_global_ctors_aux+4>: pushl %ebx
| 0x818ceb5 <__do_global_ctors_aux+5>:
| call 0x818ceba <__do_global_ctors_aux+10>
| 0x818ceba <__do_global_ctors_aux+10>: popl %ebx
| 0x818cebb <__do_global_ctors_aux+11>: addl $0x116ee,%ebx
| 0x818cec1 <__do_global_ctors_aux+17>: leal 0x6f688(%ebx),%eax
| 0x818cec7 <__do_global_ctors_aux+23>: leal 0xfffffffc(%eax),%esi
| 0x818ceca <__do_global_ctors_aux+26>: cmpl $0xffffffff,0xfffffffc(%eax)
| 0x818cece <__do_global_ctors_aux+30>:
| je 0x818cedc <__do_global_ctors_aux+44>
| 0x818ced0 <__do_global_ctors_aux+32>: movl (%esi),%eax
| 0x818ced2 <__do_global_ctors_aux+34>: call *%eax
| 0x818ced4 <__do_global_ctors_aux+36>: addl $0xfffffffc,%esi
| 0x818ced7 <__do_global_ctors_aux+39>: cmpl $0xffffffff,(%esi)
| 0x818ceda <__do_global_ctors_aux+42>:
| jne 0x818ced0 <__do_global_ctors_aux+32>
| 0x818cedc <__do_global_ctors_aux+44>: leal 0xfffffff8(%ebp),%esp
| 0x818cedf <__do_global_ctors_aux+47>: popl %ebx
| 0x818cee0 <__do_global_ctors_aux+48>: popl %esi
| 0x818cee1 <__do_global_ctors_aux+49>: leave
| 0x818cee2 <__do_global_ctors_aux+50>: ret
| 0x818cee3 <__do_global_ctors_aux+51>: nop
| 0x818cee4 <init_dummy>: pushl %ebp
| 0x818cee5 <init_dummy+1>: movl %esp,%ebp
| 0x818cee7 <init_dummy+3>: pushl %ebx
| 0x818cee8 <init_dummy+4>: call 0x818ceed <init_dummy+9>
| 0x818ceed <init_dummy+9>: popl %ebx
| 0x818ceee <init_dummy+10>: addl $0x116bb,%ebx
| End of assembler dump.
| (gdb) stepi
| 0x818ceb1 in __do_global_ctors_aux ()
| (gdb)
| 0x818ceb3 in __do_global_ctors_aux ()
| (gdb)
| 0x818ceb4 in __do_global_ctors_aux ()
| (gdb)
| 0x818ceb5 in __do_global_ctors_aux ()
| (gdb)
| 0x818ceba in __do_global_ctors_aux ()
| (gdb)
| 0x818cebb in __do_global_ctors_aux ()
| (gdb)
| 0x818cec1 in __do_global_ctors_aux ()
| (gdb)
| 0x818cec7 in __do_global_ctors_aux ()
| (gdb)
| 0x818ceca in __do_global_ctors_aux ()
| (gdb)
| 0x818cece in __do_global_ctors_aux ()
| (gdb)
| 0x818ced0 in __do_global_ctors_aux ()
| (gdb)
| 0x818ced2 in __do_global_ctors_aux ()
| (gdb)
| 0x0 in ?? ()
|
| Program received signal SIGSEGV, Segmentation fault.
| 0x0 in ?? ()
| (gdb)