Illegal Instruction caused by atexit?
Wed Oct 3 13:19:00 GMT 2001
On Wednesday 03 October 2001 13:22, David Korn wrote:
> >-----Original Message-----
> From: Larry Gray [ mailto:email@example.com ]
> >Sent: 03 October 2001 17:53
> > 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
> > 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
> >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.
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to firstname.lastname@example.org
More information about the crossgcc