FYI: powerpc EXC_LAST==0x2f00 vs. EXC_DEBUG ==0x2f10 and such?

[Justin Hibbits]

On Tuesday, May 16, 2017, Mark Millard <markmi at dsl-only.net> wrote:

> [Context:
>
> I'm having problems with production-style kernel builds
> for TARGET_ARCH=powerpc (used an old PowerMac G5 so-called
> "Quad Core") getting occasional panics that involve
> oddities like:
>
> frame->exc == 0x903a64e
>
> in the fatal kernel trap information on the console
> display.
>
> I'm not claiming the below is related but while looking
> around to figure out how to investigate I ran into
> what I report below. (The first 2 are from a block of
> 4xx / 85xx EXC_<?>'s).
> ]
>
>
> From /usr/src/sys/powerpc/include/trap.h :
>
> #define EXC_DEBUG       0x2f10          /* Debug trap */
> #define EXC_VECAST_E    0x2f20          /* Altivec Assist (Book-E) */
>
> #define EXC_LAST        0x2f00          /* Last possible exception vector
> */
>
> #define EXC_AST         0x3000          /* Fake AST vector */
>
> /* Trap was in user mode */
> #define EXC_USER        0x10000
>
> And also:
>
> /usr/src/sys/powerpc/ofw/ofw_machdep.c:char
>  save_trap_init[0x2f00];          /* EXC_LAST */
> /usr/src/sys/powerpc/ofw/ofw_machdep.c:char
>  save_trap_of[0x2f00];            /* EXC_LAST */
>
> /usr/src/sys/powerpc/include/profile.h:#define  __PROFILE_VECTOR_TOP
> (EXC_LAST + 0x100)
>
> These makes it look like EXC_LAST and some literal
> 0x2f00's might be insufficient for some contexts.
>

Nope EXC_LAST is correct as-is.  It's the last possible exception vector
for AIM, as that uses physical pages at those addresses for the exception
vectors.  Anything above EXC_LAST is an artificial exception.  Now, it does
look odd, so I should move the EXC_DEBUG and EXC_VECAST_E down below the
EXC_LAST for sorting purposes.

- Justin