Illegal instruction on m68k nommu

[Lennart Sorensen]

On Thu, Apr 16, 2009 at 10:12:26AM -0400, Lennart Sorensen wrote:
> 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.

I managed to hide the problem by commenting out the call to __app_fini
in __uClibc_main().  So something in there is blowing up on m68k.

I have no idea if that stuff comes from gcc or uclibc when you compile
a program.

-- 
Len Sorensen