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