Re: Illegal Instruction caused by atexit?

[Larry Gray <larry at greenmotor dot com>]

On Wednesday 03 October 2001 13:22, David Korn wrote:
> >-----Original Message-----
>
> From: Larry Gray [mailto:larry@greenmotor.com]
>
> >Sent: 03 October 2001 17:53
> >
> >
> >Hello,
> >	I'm trying to setup a cross compiler using newlib for
> >the ucsimm (68EZ328).
>
>     Hi Larry,
>
>   If that's one of those embedded m68k-series cpus, I can think of one
>
> possibility:
> > Newlib compiled fine, and my program compiles and link fine, however when
> > ran they give an illegal instruction. I've traced the problem down to
> > atexit, commenting this out gets me through crt0.o, but gives the same
> > error somewhere in __main.
>
>   It's that EZ in the chip id that makes me wonder, but could this perhaps
> be a cut down CPU32 variant with no FPU?  Then if the compiler or crt have
> any init/shutdown code for the FPU, and you forgot to specify -msoft-float
> when you compiled your test code, the FPU opcodes would be treated as
> illegal instructions.
>

Yes the 68EZ328 uses the 68EC000 instruction set, so I've been compiling with 
-m68000, but I've tried -mcpu32 and -msoft-float, same results.

>   If that's not it, you'll have to consider the usual possibilities - are
> you corrupting the return address on the stack?  Bearing in mind that it's
> an embedded system, does the bootloader even set up a return address for
> your app?  Does the CRT lib assume that the code is running on a bare board
> and go and set up the stack for you thereby losing your original stack and
> return address?
>

The bootloader executes from RAM, its stack pointer at the the top of RAM, it 
expects the program to be self-contained above where it runs and below its 
stack. I've set my linker script up to do this. 

>   If it's not anything simple or obvious, you could always initialise
> the exception vector to point at a routine that dumps the stack frame
> with your outbyte routine.  Then you could tell us *WHAT* instruction
> was illegal, and whether the PC was executing your code or had run off into
> space at the time of the crash.
>

I'm limited in debugging, the bootloader does not have a trace command. And 
I'm never reaching my outbyte routine. When the program dies, the bootloader 
shows the PC to be in the bootloader stack region. So apparently the stack 
gets corrupted.

> >Could this be some sort of alignment problem. I did
> >notice objdump decodes some opcodes wrong, do to alignment.
>
>   Correct me if I'm wrong, it's been a while since I worked on 68xxx
> series, but I thought that even on the CPU32+ series that can handle
> misaligned data loads and stores, instructions still had to be properly
> aligned, so objdump is probably right and you are probably in the wrong
> over that one.
>

Here is an example of my objdump:

201f2:	0000	11c0	orib #-64,%d0
201f6:	f907		fsave (cpid=4) %d7

This should be:

11c0	f907	moveb %d0,fffff907

The extra 0000 causes objdump to misintrepret the opcode, however the JSR 
goes to the right address.

Thanks,
Larry Gray
larry@greenmotor.com


>       DaveK

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com