follow-up to r332730 and r332752: set kdb_why to "trap" for fatal traps

[avg]

Summary

This change affects arm, arm64 and mips achitectures.
Additonally, it removes redundant checks for kdb_active where it
already results in kdb_reenter() and adds kdb_reenter() calls
where they were missing.

Some architectures check the return value of kdb_trap(), but some don't.
I haven't changed any of that.

Some trap handling routines have a return code.
I am not sure if I provided correct ones for returns after kdb_reenter().
It should not return unless kdb_jmpbufp is NULL for some reason.

Test Plan

Only compile tested for all affected architectures.

[jhb]

Overall I think these look ok. I haven't tested them though.

sys/arm/arm/trap-v6.c

602–603

It seems like the existing kdb_reenter() logic in this file probably should be moved to abort_fatal() similar to your change for the trap-v4.c. That is probably for someone on arm@ to test and fix, but that would seem to be more consistent with how kdb_reenter() is used on other platforms.

[skra]

In D15431#325512, @jhb wrote:

Overall I think these look ok. I haven't tested them though.

sys/arm/arm/trap-v6.c

602–603

If you mean the use of kdb_reenter() in abort_handler(), then the logic mirrors the one used in i386 trap().

[eadler]

sys/arm64/arm64/trap.c

159

shouldn't this be under the ifdef as well or am I mis-reading?

[avg]

sys/arm64/arm64/trap.c

159

Yes, it should. Thank you.

[avg]

place 'handled' under KDB, fix a whitespace issue near #ifdef

[jhb]

sys/arm/arm/trap-v6.c

602–603

Nevermind, I had misread abort_handler() as being one of the sub-handlers in aborts[].