From low level exception handling to high level...

[Piru]

I'm sorry but this is not going to work well. You have absolutely no way of knowing the state in which the system is when the exception occurs. It could well be inside some critical system semaphore being locked, and calling your high level function would just fubar the system.

The only semi-bulletproof way of doing this would be to have some signal or message being sent, and then the processing of the event would be delayed. This wouldn't be runtime processing of the exception though. And it still could be inside some critical system function where even Signal would be fatal.

One way of doing this would be to have some handler process around. At exception time a simple "frame" would be created, and it would be fed to the handler, and the offending task would be put to sleep. Then the handler would get the event, process it, and then (possibly) make the offending task continue. This would still nuke majorly if the offender is holding some semaphore the handler also wants. Exception handlers and high level functions just don't mix. Anyway, this method is what apps such as TNT and SmartCrash use. Check SmartCrash archive for source code.

[Piru]

@Karlos

Do you ever sleep?

I do. Perhaps not at the same time as others. I also like blood, and... Ehh, wait, forget that.

What if I could guarentee that the the tc_TrapCode would only be set to point to our "handler" above the implementation layer (by which I mean the place where all OS calls are made) ?

If you mean that the tc_Trapcode would be set while executing your own code. Yes, that would work. But it could still get lockup condition, unless if you really isolate ALL OS call stuff from user code (for example no user code gets to run at all with any OS lock obtained). Also, you'd naturally still need to handle the case you get exception while doing something semi-critical in your own code... But at least that is easy to predict, unlike some OS related lock ups.

[Piru]

How do you guys know all this stuff?

20 years of hacking helps.

[Piru]

The issue is that I'm not sure how to modify the 680x0 stack frame in the low level handler to get the flow of execution to return to the 'wrong' place (throwZeroDivide()) and making it appear that the original code jumped there, rather than being shoved there by the trap.

You can't do that (easily). The problem is that you'd need something similar to setjmp/longjmp to restore the register and stack to known good situation. But if you do that, you again lose ability to return to previous context.

Making the code to return to some other location is trivial. Anything else gets VERY tricky.

If you intend to get this working you need assembly at both exception and the userlevel side.

Did you check the SmartCrash src? It doesn't divert the execution at all, though.

[Piru]

This works 010+ and up at least:

Code: [Select]


addq.l #4,sp         ; pop out the exception type in stack
move.l #myfunc,2(sp) ; new return address
rte

But that's it. There is NO context saving or restoring of any kind here. The execution continues at myfunc with the stack and register at the time of the exception.

[Piru]

That is SSP.

The exec exception handler pushes 1 extra longword to stack, it's the vector number (say division by zero 0x14 >> 2 = 5 will be in stack).

Before exiting the exception handler the extra longword must be popped out of the stack. After that it's the regular stackframe in the SSP. With 68010++, all stackframes begin with:

Code: [Select]


UWORD sr;
APTR  returnaddr;

Thus poking 2(sp) with new address will make the exception return to poked address.

[Piru]

I believe in this case you're lucky to have "close" enough environment in both the code nuking and the catch part. However, I'm pretty confident this isn't always the case.

So I believe to be fully functional in all cases this thing requires some sort of state saving and restoring. For simple cases this could well be enough, however.

[Piru]

Within the supervisor mode trap, can I call FindTask(0) safely so that I can test to see if the executing task is one of my Thread instances?

Yes. FindTask(NULL) is "return SysBase->ThisTask;" basically. It's always safe.

Naturally I'd use my Thread class implementation to store the original tc_TrapCode, so that all the asm handler has to do is first ascertain if the thread is one of mine (which it should be to be even called in the first place) then if it falls through all the cmp #trapNumber, (a7) tests it can load the old tc_TrapCode from the Thread, pop it on the stack then rts to it...

I don't really want to handle things like Line A emulation errors and the like...

Sounds good.

[Piru]

Any way of getting the CPU to trap access to address zero? I am basically assuming this isn't feasable without buggering around with the MMU?

Correct, this is not possible without making the first MMU page invalid. Even then, access to bytes 4..7 must remain valid (SysBase load).

If it is feasable, that's the hardware issued NullPointerException sorted

Actually not quite, it would not catch read accesses that end up between 4..7.

Since this would require per task MMU tables, the only semi-feasible way to do it would be mmu.library.