FYI: powerpc EXC_LAST==0x2f00 vs. EXC_DEBUG ==0x2f10 and such?
Mark Millard
markmi at dsl-only.net
Sat May 20 05:30:27 UTC 2017
On 2017-May-19, at 10:24 PM, Justin Hibbits <jhibbits at freebsd.org> wrote:
On Tuesday, May 16, 2017, Mark Millard <markmi at dsl-only.net> wrote:
> . . .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.
Thanks for checking.
One other point:
save_trap_init[0x2f00] does not include 0x2500
save_trap_of[0x2f00] does not include 0x2500
But. . .
> #define EXC_LAST 0x2f00 /* Last possible exception vector */
indicates that 0x2500 is included. Is it actually
the count/bound and not the last possible?
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-ppc
mailing list