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

[Mark Millard]

On 2017-May-19, at 10:30 PM, Mark Millard <markmi at dsl-only.net> wrote:


> 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

I meant "does not include 0x2f00" in both places.

[It is a day for taking things slowly. . .]

> 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?

Same here: 0x2f00, not  0x2500.

===
Mark Millard
markmi at dsl-only.net