Robin, I guess we should have both mechanisms.
1. be able to install an exception handler directly into extable 2. be able to install an exception handler into trap_c I guess there are two pieces of functionality that I'm thinking about. Both are very different and are used for different purposes. Sorry to confuse them here. Thanks for unwinding more of the details here. Marc Robin Getz writes: > On Mon 9 Apr 2007 07:25, Marc Hoffman pondered: > > The details of the execution enviornment is really important and I > > appreciate the brick thrown. > > Marc: I don't think you understood what I meant. It was meant as : > - given that we have all these issues - does it really do what you need? > - before working on modules - lets make it easier to add things statically, > without having to modify all the existing c/assembly files - and then move > this to something that can be done with a module. > > > Lets look at the flow and make sure I > > have it right. > 0. exceptions (EVT3) are hard coded in to jump to _trap in > mach-common/entry.S by the code in mach-common/ints-priority-[ds]c.c > : > 'bfin_write_EVT3(trap)' > > 1. exception occurs > 1a. in _trap we look up the SEQSTAT_EXCAUSE, based on the _extable, and > jump to the appropriate subroutine. > r7 = SEQSTAT; /* reason code is in bit 5:0 */ > r6.l = lo(SEQSTAT_EXCAUSE); > r6.h = hi(SEQSTAT_EXCAUSE); > r7 = r7 & r6; > p5.h = _extable; > p5.l = _extable; > p4 = r7; > p5 = p5 + (p4 << 2); > p4 = [p5]; > jump (p4); > We only handle a few things in exception space - including: > .long _ex_syscall; /* 0x00 - User Defined -Linux Syscall */ > .long _ex_soft_bp /* 0x01 - User Defined -Software breakpoint > */ > .long _ex_spinlock /* 0x04 - User Defined */ > .long _ex_single_step /* 0x10 - HW Single step */ > .long _ex_dcplb /* 0x23 - Data CPLB Protection Violation */ > .long _ex_dcplb /* 0x26 - Data CPLB Miss */ > .long _ex_icplb /* 0x2B - ICPLB protection Violation */ > .long _ex_icplb /* 0x2C - Instruction CPLB miss */ > > > 2. hardware dispatches to ex_trap_c unless otherwise handled > 2a. exceptions are pushed in a buffer (to make sure that an instruction > that causes multiple exceptions is handled properly) > > 3. ex_trap_c, modifies the LVL5 hardware event handler so no > > hardware events can occur until the exception finishes (correct)? > > then the exception is deferred to LVL5. > It also allows exceptions still to occur - which gets around the > double fault issue, as well as handling single instructions which > cause multiple exceptions. > > 4. trap_c is called from LVL5. > > 5. handled events are covered via switch(event) construct in C. > Because they are normally error conditions: > > .long _ex_trap_c /* 0x03 - User Defined -Atomic test and set*/ > .long _ex_trap_c /* 0x11 - Trace Buffer Full */ > .long _ex_trap_c /* 0x21 - Undefined Instruction */ > .long _ex_trap_c /* 0x22 - Illegal Instruction Combination */ > .long _ex_trap_c /* 0x24 - Data access misaligned */ > .long _ex_trap_c /* 0x25 - Unrecoverable Event */ > .long _ex_trap_c /* 0x27 - Data CPLB Multiple Hits-Trap Zero > */ > .long _ex_trap_c /* 0x28 - Emulation Watchpoint */ > .long _ex_trap_c /* 0x29 - Ifetch access error(535 only) */ > .long _ex_trap_c /* 0x2A - Instruction fetch misaligned */ > .long _ex_trap_c /* 0x2D - Instruction CPLB Multiple Hits */ > .long _ex_trap_c /* 0x2E - Ill use of Supervisor Resource */ > .long _ex_trap_c /* 0x2E - Ill use of Supervisor Resource */ > > Because we are in EVT5, and no other events can occur - we end up > with > problems sometimes (For example - it takes a long time to print out > things, during an error and the watchdog (if set) will trigger during > this time, causing a reset of the processor) > > > Here is another example of a place where one might want to modify the > > exception handling behavior. Illegal instruction I want the ability > > to write simulation semantics that provides in a similar way > > architectural extensions they might be slow. > > So, do you want to be able to write into the ex_table? (and replace the > _ex_trap_c entry)? Your routine would either handle it, or jump back to > _ex_trap_c. The kernel shouldn't know the difference. > > > Now the question turns to how does one make trap_c mutable? > > Is that the question? If speed is the answer - I am not sure that will help > much - the path to take a system/kernel call isn't that much different than > the path the trap_c. > > If the design goal is speed in handling the event, I think we would want to > trap things at the highest level possible (in exception space, before > defering to level5). However, doing things in level5 has it's advantages, > since you can't generate double fault events, you can handle CPLB misses, so > a module would work easily. > > -Robin _______________________________________________ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
