Illegal instruction on m68k nommu

[Lennart Sorensen]

On Thu, Apr 16, 2009 at 05:05:20PM -0400, Lennart Sorensen wrote:
> I tried initializing it to 0, and no help.
> 
> Now I also treid changing -1 to -3 and that made it no longer blow up
> (perhaps because it no longer has anything to call).
> 
> The last element should be NULL.
> 
> My understanding is that DTOR_LIST contains either the number of entries
> or -1 (depends on the system style), and then is supposed to be followed
> by an array of function pointers, and be null terminated.
> 
> I tried adding a 'if not NULL, call f ()' but that didn't help either.
> I still got Illegal instruction in that case.
> 
> Commenting out the f () call, or changing -1 to -3, both make the Illegal
> instruction go away.  So does disabling global contructor/destructor
> support in uclibc of course, but I didn't really want to do that (and
> it seems to cause some problems compiling gcc 4.3.3 if I do that too).
> 
> I could send the objdump of the symbol tables and assembly of my test
> program if anyone can make more sense of it than I am.

So I tried changing gcc-4.3.3/gcc/crtstuff.c:

#ifdef FINI_ARRAY_SECTION_ASM_OP
  /* If we are using .fini_array then destructors will be run via that
     mechanism.  */
#elif defined(HIDDEN_DTOR_LIST_END)
  {
    /* Safer version that makes sure only .dtors function pointers are
       called even if the static variable is maliciously changed.  */
    extern func_ptr __DTOR_END__[] __attribute__((visibility ("hidden")));
    static size_t dtor_idx;
    const size_t max_idx = __DTOR_END__ - __DTOR_LIST__ - 1;
    func_ptr f;

    while (dtor_idx < max_idx)
      {
        f = __DTOR_LIST__[++dtor_idx];
        f ();
      }
  }
#else /* !defined (FINI_ARRAY_SECTION_ASM_OP) */
  {
    static func_ptr *p = __DTOR_LIST__ + 1;
    func_ptr f;

    while ((f = *p))
      {
        p++;
        f ();
      }
  }
#endif /* !defined(FINI_ARRAY_SECTION_ASM_OP) */

by changing the #elif to:

#elif 0 && defined(HIDDEN_DTOR_LIST_END)

which forced it back to the #else, which was the code gcc 4.1.x used.
And that seems to make the problem go away.

I now wonder if there is a bug in that gcc 4.3 code, or in the linker
messing up the ordering, or possibly in the elf2flt tool.

Is it time for me to go bother the gcc or binutils developers for clues?

-- 
Len Sorensen