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

[Jeffrey A Law <law at cygnus dot com>]

  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