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