This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Illegal Instruction caused by atexit?


>-----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.

  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?

  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.

>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.

      DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]