i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

I can build emacs-20.2 using egcs-980531, but more recent snapshots
(starting a week or two ago) can no longer build it.  Here's the
failure I get using a recent snapshot (I updated last night):

  ./configure && make

  ...

  Dumping under names emacs and emacs-20.2.1
  414008 pure bytes used
  ./emacs -q -batch -f list-load-path-shadows
  make[1]: *** [emacs] Segmentation Fault
  make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/src'
  cd leim; make -j2 all -j 1 \
    CC='gcc' CFLAGS='-g -O ' CPPFLAGS='' \
    LDFLAGS='' MAKE='make -j2'
  make[1]: Entering directory `/d/pd/emacs/stable/emacs-20.2/leim'
  make[1]: Nothing to be done for `all'.
  make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/leim'

  $ gcc -v
  Reading specs from /p/p/egcs-980619-21h10/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.41/specs
  gcc version egcs-2.91.41 19980619 (gcc2 ss-980502 experimental)

  $ as -v
  GNU assembler version 2.9.1 (i386-pc-solaris2.5.1), using BFD version 2.9.1

Building with the official snapshot, egcs-980531, worked fine.

Running the failing command under the debugger didn't help me:

  $ gdb emacs
  DISPLAY = :0.0
  TERM = xterm
  Breakpoint 1 at 0x8071a4c
  Breakpoint 2 at 0x80a4e0a: 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) bt
  #0  0x0 in ?? ()
  #1  0x812f72c in __do_global_ctors_aux ()
  #2  0x812f775 in _init ()
  (gdb)

Any suggestions?

BTW, if I had more disk space (or if I'd been omitting symbols :-)
I'd be keeping around lots more snapshots and would have been able to
determine (conveniently) more precisely when gcc stopped being able to
build emacs-20.2.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

Hi,

I have just confirmed that current sources as of about 980714-08h24
still exhibit the problem I reported three weeks ago.  For all I know,
this could be a problem with emacs, solaris5.5.1, or some tool in my
build environment.

Has anyone built a recent version of emacs (20.2 or newer test releases)
with an egcs snapshot from June or later?

Jim

I wrote:
| I can build emacs-20.2 using egcs-980531, but more recent snapshots
| (starting a week or two ago) can no longer build it.  Here's the
| failure I get using a recent snapshot (I updated last night):
|
|   ./configure && make
|
|   ...
|
|   Dumping under names emacs and emacs-20.2.1
|   414008 pure bytes used
|   ./emacs -q -batch -f list-load-path-shadows
|   make[1]: *** [emacs] Segmentation Fault
|   make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/src'
|   cd leim; make -j2 all -j 1 \
|     CC='gcc' CFLAGS='-g -O ' CPPFLAGS='' \
|     LDFLAGS='' MAKE='make -j2'
|   make[1]: Entering directory `/d/pd/emacs/stable/emacs-20.2/leim'
|   make[1]: Nothing to be done for `all'.
|   make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/leim'
|
|   $ gcc -v
|   Reading specs from /p/p/egcs-980619-21h10/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.41/specs
|   gcc version egcs-2.91.41 19980619 (gcc2 ss-980502 experimental)
|
|   $ as -v
|   GNU assembler version 2.9.1 (i386-pc-solaris2.5.1), using BFD version 2.9.1
|
| Building with the official snapshot, egcs-980531, worked fine.
|
| Running the failing command under the debugger didn't help me:
|
|   $ gdb emacs
|   DISPLAY = :0.0
|   TERM = xterm
|   Breakpoint 1 at 0x8071a4c
|   Breakpoint 2 at 0x80a4e0a: 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) bt
|   #0  0x0 in ?? ()
|   #1  0x812f72c in __do_global_ctors_aux ()
|   #2  0x812f775 in _init ()
|   (gdb)
|
| Any suggestions?
|
| BTW, if I had more disk space (or if I'd been omitting symbols :-)
| I'd be keeping around lots more snapshots and would have been able to
| determine (conveniently) more precisely when gcc stopped being able to
| build emacs-20.2.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Dave Love]

I have two data:

This is posted from the current pretest built with an essentially
current egcs on i586-pc-linux-gnu (mostly vanilla RedHat 5.1).

I've failed to build both Emacs 19.34 and 20.2 on an older x86 Debian
(libc5-based) system with a similar-looking symptom to the one in
question, using both gcc 2.7 and gcc 2.8.  I couldn't debug it and put
it down to some funny specific to that box, but perhaps it wasn't.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jeffrey A Law]

  In message < 87sok3zs6t.fsf@eng.ascend.com >you write:
  > Hi,
  > 
  > I have just confirmed that current sources as of about 980714-08h24
  > still exhibit the problem I reported three weeks ago.  For all I know,
  > this could be a problem with emacs, solaris5.5.1, or some tool in my
  > build environment.
  > |   Program received signal SIGSEGV, Segmentation fault.
  > |   0x0 in ?? ()
  > |   (gdb) bt
  > |   #0  0x0 in ?? ()
  > |   #1  0x812f72c in __do_global_ctors_aux ()
  > |   #2  0x812f775 in _init ()
  > |   (gdb)
  > |
  > | Any suggestions?
  > |
  > | BTW, if I had more disk space (or if I'd been omitting symbols :-)
  > | I'd be keeping around lots more snapshots and would have been able to
  > | determine (conveniently) more precisely when gcc stopped being able to
  > | build emacs-20.2.
You might try disassembling __do_global_ctors_aux to see if it looks
reasonable.  Or you might compile all the libgcc code & crtstuff
with "-g" so that you can debug __do_global_ctors_aux.

jeff

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[David S. Miller]

   From: Jim Meyering <meyering@ascend.com>
   Date: 14 Jul 1998 22:52:42 -0500

   I have just confirmed that current sources as of about 980714-08h24
   still exhibit the problem I reported three weeks ago.  For all I
   know, this could be a problem with emacs, solaris5.5.1, or some
   tool in my build environment.

   Has anyone built a recent version of emacs (20.2 or newer test
   releases) with an egcs snapshot from June or later?

I did some research into this and I have an emacs tree which reliably
reproduces the problem you are seeing, but for me on sparc-linux
targets.

When I vary the CFLAGS settings during the build, it changes the
results, and I can get working executables.

One thing you can note in the failure cases is that the impure
'temacs' is just fine and will run perfectly.  In your case and in
mine, running 'ldd temacs' will show all the dynamically linked
libraries 'temacs' uses.  However, the 'emacs' binary which crashes
will be reported as static linked by ldd :-)

The best I could determine using gdb was that the 'emacs' binary
crashes inside of the dynamic linker very early on in execution.

My best guess at this point is that current egcs emits something which
results in ELF images which confuse the unexec() mechanism which emacs
uses, thus making it dump corrupt executables.

I'll try to track this down further as time permits.  Thanks for the
report.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[David S. Miller]

   Date: Thu, 16 Jul 1998 05:36:32 -0700
   From: "David S. Miller" <davem@dm.cobaltmicro.com>

   I'll try to track this down further as time permits.  Thanks for the
   report.

Replying to myself...

Jim, I believe i have tracked it down, so could you do some
experiments for me?

In my case I have found that the GCSE pass mis-optimizes the code in
unexelf.c  When I recompile it with "-O2 -fno-gcse" I get a properly
functioning emacs build.

Could you try to recompile unexelf.o without any optimizations, and
see if this allows the resulting emacs to work just fine?

Using this, I can determine whether we are seeing the same bug.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Horst von Brand]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

"David S. Miller" <davem@dm.cobaltmicro.com> said:
> Jim Meyering <meyering@ascend.com> said:
>    Has anyone built a recent version of emacs (20.2 or newer test
>    releases) with an egcs snapshot from June or later?
> I did some research into this and I have an emacs tree which reliably
> reproduces the problem you are seeing, but for me on sparc-linux
> targets.

My emacs-20.2 (stock GNU source) was compiled with egcs:

GNU Emacs 20.2.1 (i586-redhat-linux-gnu, X toolkit) of Mon Jul  6 1998 on
sleipnir

Must have been egcs-19980628, -O2 -fomit-frame-pointer -march=pentium. Note
I'm using a (somewhat patched) glibc-2.0.94, binutils-2.9.1.0.6 at the
time. 

Works fine. No idea if this is in any way relevant...

Will try and see what the latest egcs gives on sparc-sun-solaris2.5.1 if
time allows.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

"David S. Miller" <davem@dm.cobaltmicro.com> writes:

|    Date: Thu, 16 Jul 1998 05:36:32 -0700
|    From: "David S. Miller" <davem@dm.cobaltmicro.com>
|
|    I'll try to track this down further as time permits.  Thanks for the
|    report.
|
| Replying to myself...
|
| Jim, I believe i have tracked it down, so could you do some
| experiments for me?
|
| In my case I have found that the GCSE pass mis-optimizes the code in
| unexelf.c  When I recompile it with "-O2 -fno-gcse" I get a properly
| functioning emacs build.
|
| Could you try to recompile unexelf.o without any optimizations, and
| see if this allows the resulting emacs to work just fine?
|
| Using this, I can determine whether we are seeing the same bug.

Thanks!

Unfortunately, even compiling all of emacs with -g
(or with empty CFLAGS) didn't change the result:

  Loading loaddefs.el...
  Loading vc-hooks (compiled)...
  Loading ediff-hook (compiled)...
  Finding pointers to doc strings...
  Finding pointers to doc strings...done
  Dumping under names emacs and emacs-20.2.2
  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.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[David S. Miller]

   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.

Thanks again for the help so far.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

Jeffrey A Law <law@hurl.cygnus.com> writes:

|   In message < 87pvf4pl6t.fsf@ascend.com >you write:
|
|   >   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.
| I'm not aware of any reason why that would be true.  But anyway....

Oops.
It was crtbegin.o (not crtstuff.c) that I couldn't build with -g.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

| I wrote:
| | I can build emacs-20.2 using egcs-980531, but more recent snapshots
| | (starting a week or two ago) can no longer build it.  Here's the
| | failure I get using a recent snapshot (I updated last night):

I just built emacs-20.2 using the egcs-19980608 snapshot.  So now, I think
it was a change made in the week or 10 days following the June 8 snapshot.

The 0615 snapshot didn't bootstrap -- more later.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jeffrey A Law]

  In message < 87pvf4pl6t.fsf@ascend.com >you write:

  >   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.
I'm not aware of any reason why that would be true.  But anyway....

[ ... ]

  > stepping throught that, I made it into __register_frame_info
  > and back to 0x818cf05.  thence into __do_global_ctors_aux:
OK.

  >       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>

The call at 0x818ced2 is jumping to location zero.

Look at what's in the __CTOR_LIST__ before and after unexec; of particular
interest will be the first word at that address (if nonzero, it tell the
init code how many ctors to fire).

The remaining entries are a list of function pointers.

Based on the info I've seen I'd bet the first word is nonzero, but the
second word is zero, causing __do_global_ctors_aux to jump to zero.  This
would most likely indicate an unexec problem of some kind.

jeff

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[David S. Miller]

   Date: Fri, 17 Jul 1998 10:14:09 -0600
   From: Jeffrey A Law <law@hurl.cygnus.com>

   Based on the info I've seen I'd bet the first word is nonzero, but
   the second word is zero, causing __do_global_ctors_aux to jump to
   zero.  This would most likely indicate an unexec problem of some
   kind.

It could be that unexecelf is being confused by the ELF layouts which
egcs produces in the executable.  Essentially unexecelf just figures
out the live ELF section boundaries, extends the BSS to include the
lisp code loaded in, and dumps these into the resulting executable.

There are two areas which might prove fruitful to investigate:

1) Do the resulting executables violate some of the assumptions
   about how certain text/data/bss symbols represent the boundaries of
   said sections?

2) Is the dwarf2 unwind info on x86 creating ELF object files which
   confuse unexelf in some way to output corrupt images?

In any event, it appears that the bug I have seen wrt. emacs builds
with egcs, and the one being seen here on x86 are two seperate bugs.
This I am sure of.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

"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)

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

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)

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jeffrey A Law]

  In message < 873eawf8n0.fsf@ascend.com >you write:
  > 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?
cvs-1.9.21, but that really shouldn't have anything to do with being unable
to bootstrap egcs

What problems are you having bootstrapping?

x86-solaris testers are few and far between.  I do see that someone
bootstrapped x86-solaris and ran the testsuite with the egcs-19980621
snapshot (Jorg Pietschmann <pietsch@swissline.ch>).

jeff

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jeffrey A Law]

  In message < 87yasnenke.fsf@ascend.com >you write:
  > Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  > |   In message < 873eawf8n0.fsf@ascend.com >you write:
  > |   > 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?
  > | cvs-1.9.21, but that really shouldn't have anything to do with being unab
  > le
  > | to bootstrap egcs
  > |
  > | What problems are you having bootstrapping?
  > 
  > Here's what I got when trying to bootstrap the official egcs-19980615
  > snapshot:
[ ... ]
OK.  This has nothing to do with whatever cvs version we're running.  It 
sounds more like the typical development instability.  What happens if
you try to build something newer, paricularly off the egcs-1.1  branch?
jeff

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jeffrey A Law]

  In message < 87iujrs9ax.fsf@ascend.com >you write:
  > | OK.  This has nothing to do with whatever cvs version we're running.  It
  > | sounds more like the typical development instability.  What happens if
  > | you try to build something newer, paricularly off the egcs-1.1  branch?
  > 
  > I've been doing that (with the trunk, then, since the branch, with 1.1)
  > for more than a month.  It works fine.  Of course, using the resulting
  > compiler to try to build emacs is what fails.
I'm really confused -- look back at what you said a little while ago:

|   > |   In message < 873eawf8n0.fsf@ascend.com >you write:
|   > |   > 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?

So in fact, you can bootstrap, but we still have problems with XEmacs
right?

jeff

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

|   In message < 87yasnenke.fsf@ascend.com >you write:
|   > Jeffrey A Law <law@hurl.cygnus.com> writes:
|   >
|   > |   In message < 873eawf8n0.fsf@ascend.com >you write:
|   > |   > 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?
|   > | cvs-1.9.21, but that really shouldn't have anything to do with being unab
|   > le
|   > | to bootstrap egcs
|   > |
|   > | What problems are you having bootstrapping?
|   >
|   > Here's what I got when trying to bootstrap the official egcs-19980615
|   > snapshot:
| [ ... ]
| OK.  This has nothing to do with whatever cvs version we're running.  It
| sounds more like the typical development instability.  What happens if
| you try to build something newer, paricularly off the egcs-1.1  branch?

I've been doing that (with the trunk, then, since the branch, with 1.1)
for more than a month.  It works fine.  Of course, using the resulting
compiler to try to build emacs is what fails.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

|   In message < 87yasnenke.fsf@ascend.com >you write:
|   > Jeffrey A Law <law@hurl.cygnus.com> writes:
|   >
|   > |   In message < 873eawf8n0.fsf@ascend.com >you write:
|   > |   > 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?
|   > | cvs-1.9.21, but that really shouldn't have anything to do with being unab
|   > le
|   > | to bootstrap egcs
|   > |
|   > | What problems are you having bootstrapping?
|   >
|   > Here's what I got when trying to bootstrap the official egcs-19980615
|   > snapshot:
| [ ... ]
| OK.  This has nothing to do with whatever cvs version we're running.  It
| sounds more like the typical development instability.  What happens if
| you try to build something newer, paricularly off the egcs-1.1  branch?
| jeff

Whoops.  I misunderstood.
I have *not* been doing `cvs update -DDATE' for a month.
I'm convinced that it's just instability as you say.

The problem is that I didn't have time to find out which subsequent
patch fixed the bootstrap problem I saw when trying to localize the
emacs-build-breaking change.  Unfortunately, I don't expect to have
much time to work on this for the next week or so -- I'll be offline
from Thur through Mon.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

|   In message < 87iujrs9ax.fsf@ascend.com >you write:
|   > | OK.  This has nothing to do with whatever cvs version we're running.  It
|   > | sounds more like the typical development instability.  What happens if
|   > | you try to build something newer, paricularly off the egcs-1.1  branch?
|   >
|   > I've been doing that (with the trunk, then, since the branch, with 1.1)
|   > for more than a month.  It works fine.  Of course, using the resulting
|   > compiler to try to build emacs is what fails.
| I'm really confused -- look back at what you said a little while ago:
|
| |   > |   In message < 873eawf8n0.fsf@ascend.com >you write:
| |   > |   > 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?
|
| So in fact, you can bootstrap, but we still have problems with XEmacs right?

*X*Emacs?  could you be thinking of something different?  I saw a thread
about an abort with XEmacs.  This is a segfault that happens during the
make process for *FSF* emacs-20.2 (and 20.2.99) when the just-created
emacs executable is run like this:

  ../src/emacs -batch --no-init-file --no-site-file --multibyte ...

I bootstrapped the head of egcs-1.1 after the last change and installed it.
I cannot build a working FSF emacs 20.2 using that compiler.

  Reading specs from \
    /p/p/egcs-980817-00h35/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.54/specs
  gcc version egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)

Note that compiling and linking go just fine.
David Miller hypothesized that the failure is related to the unexec.

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jim Meyering]

Jeffrey A Law <law@hurl.cygnus.com> writes:

|   In message < 873eawf8n0.fsf@ascend.com >you write:
|   > 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?
| cvs-1.9.21, but that really shouldn't have anything to do with being unable
| to bootstrap egcs
|
| What problems are you having bootstrapping?

Here's what I got when trying to bootstrap the official egcs-19980615
snapshot:

  make[1]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/libiberty'
  make[1]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/libiberty'
  make[1]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo'
  make all-recursive
  make[2]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo'
  Making all in intl
  make[3]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/intl'
  make[3]: Nothing to be done for `all'.
  make[3]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/intl'
  Making all in lib
  make[3]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/lib'
  make[3]: Nothing to be done for `all'.
  make[3]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/lib'
  Making all in makeinfo
  make[3]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/makeinfo'
  make[3]: Nothing to be done for `all'.
  make[3]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/makeinfo'
  make[2]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo'
  make[1]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo'
  Bootstrapping the compiler
  make[1]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/gcc'
  make CC="stage1/xgcc -Bstage1/" CFLAGS="-W -Wall -O2 -g -O2" LDFLAGS="" libdir=/p/p/egcs-19980615/lib STAGE_PREFIX=stage1/ LANGUAGES="c proto gcov  c++ f77 objc"
  make[2]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/gcc'
  stage1/xgcc -Bstage1/ -c  -DIN_GCC    -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H     -I. -I../../gcc -I../../gcc/config ../../gcc/c-lex.c
  ../../gcc/c-gperf.h: In function `hash':
  In file included from ../../gcc/c-lex.c:130:
  ../../gcc/c-gperf.h:43: warning: array subscript has type `char'
  ../../gcc/c-gperf.h:46: warning: array subscript has type `char'
  ../../gcc/c-gperf.h:49: warning: array subscript has type `char'
  ../../gcc/c-lex.c: In function `readescape':
  ../../gcc/c-lex.c:923: warning: comparison between signed and unsigned
  ../../gcc/c-lex.c: In function `yylex':
  ../../gcc/c-lex.c:1823: warning: comparison between signed and unsigned
  ../../gcc/c-lex.c:1054: warning: variable `c' might be clobbered by `longjmp' or `vfork'
  ../../gcc/c-lex.c:1055: warning: variable `p' might be clobbered by `longjmp' or `vfork'
  ../../gcc/c-lex.c:1443: warning: variable `type' might be clobbered by `longjmp' or `vfork'
  ../../gcc/c-lex.c:1444: warning: variable `imag' might be clobbered by `longjmp' or `vfork'
  ../../gcc/c-lex.c:1445: warning: variable `conversion_errno' might be clobbered by `longjmp' or `vfork'
  ../../gcc/global.c:401: Internal compiler error in function global_alloc
  make[2]: *** [c-lex.o] Error 1
  make[2]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/gcc'
  make[1]: *** [bootstrap2] Error 2
  make[1]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/gcc'
  make: *** [bootstrap2] Error 2

| x86-solaris testers are few and far between.  I do see that someone
| bootstrapped x86-solaris and ran the testsuite with the egcs-19980621
| snapshot (Jorg Pietschmann <pietsch@swissline.ch>).
|
| jeff

Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2

[Jeffrey A Law]

  In message < 87af53s88r.fsf@ascend.com >you write:
  > *X*Emacs?  could you be thinking of something different?  I saw a thread
  > about an abort with XEmacs.  This is a segfault that happens during the
  > make process for *FSF* emacs-20.2 (and 20.2.99) when the just-created
  > emacs executable is run like this:
Sorry.  A thinko/typo on my part.

  >   ../src/emacs -batch --no-init-file --no-site-file --multibyte ...
  > 
  > I bootstrapped the head of egcs-1.1 after the last change and installed it.
  > I cannot build a working FSF emacs 20.2 using that compiler.
  > 
  >   Reading specs from \
  >     /p/p/egcs-980817-00h35/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.54/sp
  > ecs
  >   gcc version egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)
  > 
  > Note that compiling and linking go just fine.
  > David Miller hypothesized that the failure is related to the unexec.
Right.  And more specifically you're calling to location zero out
of do_global_something.  So I think you need to look at the global
ctor/dtor lists before and after the unexec to see if they make sense.

jeff