Should the bit fields in ptrace.h? So then it would be #ifdef CONFIG_COLDFIRE unsigned format : 4; /* frame format specifier */ + unsigned fault_status_H : 2; - unsigned vector : 8; /* vector offset */ + unsigned vector : 12; /* vector offset */ + unsigned fault_status_L : 2; unsigned short sr; unsigned long pc;
It seems that there are implications in signal handling, though. - Jate S. -----Original Message----- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Greg Ungerer Sent: Thursday, October 07, 2010 3:28 AM To: uClinux development list Subject: Re: [uClinux-dev] Wrong exception handling on m68knommu Coldfire 5208? Hi Alexander, Sorry for the really slow response on this... On 02/06/09 17:31, Alexander Stein wrote: > I'm experiencing several illegal instruction errors during execution > of some programs. Using a BDM debugger I got until the parsing of the > exception stack inside trap_c() (arch/m68knommu/kernel/traps.c) where I > stumbled. > The exception vector is extracted as followed: >> switch ((fp->ptregs.vector)>> 2) > The reference manual for Coldfire 5208 chapter 3.3.3.1 describe the following: >> SSP Format(bits 31-28), FS[3:2](bits 27, 26), Vector(bits 25:18), >> FS[1:0] > (bits 17, 16), Status Register (bits 15-0) >> SSP + 0x4 Prgram Counter (bits 31-0) > > In my opinion the vector extraction is wrong, because the vector is > defined with 12 Bits in size (see include/asm-m68knommu/ptrace.h) > including the Fault Status bits at each end of those 12 bits. By just > shifting 2 bits to the right you will still have FS[3:2] at the upper > end of ptregs.vector resulting in a wrong exception vector, if a bit > is set in FS[3:2] So I think the vector extraction has to be changed to > something like that: >> switch (((fp->ptregs.vector)>> 2)& 0xff) Yes, you are absolutely correct. > With that change (at every occurrence) I get at least a bus error > instead (the kernel want to execute at address 0xffffffff, but that's > another problem) of illegal instruction, which seems to be a default > exception handler. > > I used uClinux-dist-20080808, but I noticed this lines of code didn't > change in uClinux-dist-20090520 and even linux-2.6. AFAIK the > exception stack is the same on Coldfire 5484 (V4e core with MMU). Yes, I am pretty sure it is the same on all. Attached is the patch I propose to push up-stream to fix this. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
