Illegal instruction on m68k nommu

[Lennart Sorensen]

On Wed, Apr 15, 2009 at 01:53:01PM -0400, Lennart Sorensen wrote:
> I am trying to track down why all my programs terminate with "Illegal
> instruction".
> 
> My test program currently is:
> 
> int main() {
> 	return 42;
> }
> 
> When compiled using gcc 4.3.3+binutils 2.19.1 for m68k-uclinux with the command:
> m68k-uclinux-gcc -mcpu=5271 -msep-data -Wall -o test42 test42.c
> 
> I run it, and getan illegal instruction.  If I make the program do
> something else before returning, all that does happen, so the problem
> is happening somewhere in the exit functions.
> 
> Now to try and track it down I tried doing:
> 
> int main() {
> 	_exit(42);
> }
> 
> And this program in fact terminates cleanly, returning 42, and does not
> have any illegal instruction problem.
> 
> Does anyone have a suggestion for how to track down what is going wrong
> in the destructors or whatever else is happening on exit that could be
> causing the problem?
> 
> This problem did not happen with an older uclibc (0.9.27) and older
> gcc and binutils (4.1.1 + 2.16), but unfortunately those are not
> able to compile some of the code I have, due to too many relocations
> or something.  gcc 4.3 now use a global offset table on m68k-uclinux
> which seems to solve that problem very nicely, and my program does run,
> it just terminates badly.  The bad termination causes problems with
> trying to use pipes in msh since the programs in the start of the pipe
> sequence blow up before the end of the pipe is done working, and takes
> the whole pipe with it.
> 
> I know gcc 4.3 and/or binutils 2.19.1 also breaks uboot on the coldfire,
> but again it may have to do with the abi change gcc 4.3 did.  Not sure
> though, since using gcc 4.1 along with binutils 2.19.1 doesn't seem to
> fix uboot either, although uclibc with my test program compiled with
> gcc 4.1.1 with the new binutils works fine.

So it now appears that building uclibc with UCLIBC_CTOR_DTOR disabled,
makes the problem go away.  Not very convinient, but at least a clue.

-- 
Len Sorensen