Illegal instruction on m68k nommu

[Lennart Sorensen]

On Thu, Apr 16, 2009 at 01:26:33PM -0700, Carl Miller wrote:
> On Thu, Apr 16, 2009 at 04:03:51PM -0400, Lennart Sorensen wrote:
> > On Thu, Apr 16, 2009 at 12:11:37PM -0400, Lennart Sorensen wrote:
> > > Can anyone tell me where the function pointer _fini being put on the
> > > stack in m68k/crt1.S comes from.  Is it uclibc or gcc or what?  once I
> > > find it, I might actually be able to find out what it is causing an
> > > illegal instruction to happen.
> > 
> > So I have traced it down to a call in crtstuff.c in gcc 4.3.3:
> > 
> >   {
> >     /* 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 ();
> >       }
> >   }
> > 
> > The call to 'f ();' is where it hits the illegal instruction.
> > 
> > How do I add print statements or something else that I can use to debug
> > code in this area.
> > 
> > I have suspicions about the calculation of max_idx, since it seems to want
> > to calculate the number of entries, yet I think it is using addresses
> > in it's calculation, which seems like it ought to give a larger value
> > than intended.
> 
> That part passes my smell test.  It's subtracting one pointer from
> another, which should give the number of pointed-to objects that fit
> between them, which would be correct.
> 
> Here's what smells fishy to me:  where does dtor_idx get initialized?
> If it's relying on an implicit zero initialization, is that happening?
> And even if it is, is that the correct initialization value?  Given
> the pre-increment, it looks to me like a -1 initial value might be
> called for.  (The last element of the DTOR_LIST is supposed to be NULL,
> correct?  That's why the '- 1' term is in the calculation of max_idx,
> yes?)

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.

-- 
Len Sorensen