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