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 0x, 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 EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
[PATCH] m68knommu: mask of vector bits in exception word properly
The vector field of the processors exception frame actually contains
both the vector exception number and fault status field bits.
The exception processing code was not correctly masking out the
fault status field bits before switching on the vector number.
The default case was catching the bad check, but we are reporting
the wrong kind of exception in some cases.
Problem reported by alexander.st...@systec-electronic.com.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68knommu/kernel/traps.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/m68knommu/kernel/traps.c b/arch/m68knommu/kernel/traps.c
index e8b813d..a768008 100644
--- a/arch/m68knommu/kernel/traps.c
+++ b/arch/m68knommu/kernel/traps.c
@@ -179,14 +179,16 @@ static void __show_stack(struct task_struct *task, unsigned long *stack)
void bad_super_trap(struct frame *fp)
{
+ int vector = (fp-ptregs.vector 2) 0xff;
+
console_verbose();
- if (fp-ptregs.vector 4 * ARRAY_SIZE(vec_names))
+ if (vector ARRAY_SIZE(vec_names))
printk (KERN_WARNING *** %s *** FORMAT=%X\n,
- vec_names[(fp-ptregs.vector) 2],
+ vec_names[vector],
fp-ptregs.format);
else
printk (KERN_WARNING *** Exception %d *** FORMAT=%X\n,
- (fp-ptregs.vector) 2,
+ vector,
fp-ptregs.format);
printk (KERN_WARNING Current process id is %d\n, current-pid);
die_if_kernel(BAD KERNEL TRAP, fp-ptregs, 0);
@@ -195,10 +197,11 @@ void bad_super_trap(struct frame *fp)
asmlinkage void trap_c(struct frame *fp)
{
int sig;
+ int vector = (fp-ptregs.vector 2) 0xff;
siginfo_t info;
if (fp-ptregs.sr PS_S) {
- if ((fp-ptregs.vector 2) == VEC_TRACE) {
+ if (vector == VEC_TRACE) {
/* traced a trapping instruction */
} else
bad_super_trap(fp);
@@ -206,7 +209,7 @@ asmlinkage void trap_c(struct frame *fp)
}
/* send the appropriate signal to the user program */
- switch ((fp-ptregs.vector) 2) {
+ switch (vector) {
case VEC_ADDRERR:
info.si_code = BUS_ADRALN;
sig = SIGBUS;
___
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
Re: [uClinux-dev] Wrong exception handling on m68knommu Coldfire 5208?
On Thu, Oct 07, 2010 at 05:27:36PM +1000, Greg Ungerer wrote: Sorry for the really slow response on this... Glad to see you here again :) Problem reported by alexander.st...@systec-electronic.com. I think there is now a standardized keyword for that : Reported-by: Alexander Stein alexander.st...@systec-electronic.com Philippe ___ 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
RE: [uClinux-dev] Wrong exception handling on m68knommu Coldfire 5208?
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 0x, 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 EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: 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
RE: [uClinux-dev] Wrong exception handling on m68knommu Coldfire 5208?
Quoth Jate Sujjavanich: 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; Aren't those two middle changes reversed? (ie. should be changing vector from a 12 bit field to an 8 bit field, not the reverse.) ___ 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
Re: [uClinux-dev] Wrong exception handling on m68knommu Coldfire 5208?
On 07/10/10 22:46, Philippe De Muyter wrote: On Thu, Oct 07, 2010 at 05:27:36PM +1000, Greg Ungerer wrote: Sorry for the really slow response on this... Glad to see you here again :) I am always here :-) A pitfall of an over stuffed mail box. Sometimes I miss things I mean to get to... Problem reported by alexander.st...@systec-electronic.com. I think there is now a standardized keyword for that : Reported-by: Alexander Stein alexander.st...@systec-electronic.com Ok, thanks. I change the commit message to use this. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ 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
Re: [uClinux-dev] Wrong exception handling on m68knommu Coldfire 5208?
Hi Jate, On 08/10/10 01:59, Jate Sujjavanich wrote: 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. Yes, and that is partly why I was reluctant to change this. And there is a much larger problem to deal with here. ptrace.h is part of the user API (it is an exported header). But CONFIG_COLDFIRE won't exist in the normal user space build process - it is a kernel define. So in a sense any user-space user of ptrace.h on ColdFire is not going to see these correct unless they manually defined CONFIG_COLDFIRE... I guess there isn't too much user space code that relies on these fields - otherwise they would be complaining :-) Regards Greg -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 0x, 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 EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: 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 -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ 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
