Illegal instruction on m68k nommu
Carl Miller
chaz at energoncube.net
Thu Apr 16 20:26:33 UTC 2009
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?)
Carl Miller
Firmware Engineer
DriveCam, Inc.
More information about the uClibc
mailing list