[ECOS] Exception support for i386

[ECOS] Exception support for i386

[Fabrice Gautier]

Hi,

There is actually no support for exceptions for the i386 PC platform.

I'm wondering what should be the interaction between the kernel, the Hal
and  the gdb stub about this.

Should the gdb stub handle all exceptions with is own handle and then,
eventually, call the kernel handler?

Or should the gdb stub use the kernel routine to install his exception
handlers like ant other?

How is it done in others arch?

Thanks

A+
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Exception support for i386

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> Hi,
> 
> There is actually no support for exceptions for the i386 PC platform.
> 
> I'm wondering what should be the interaction between the kernel, the Hal
> and  the gdb stub about this.
> 
> Should the gdb stub handle all exceptions with is own handle and then,
> eventually, call the kernel handler?
> 
> Or should the gdb stub use the kernel routine to install his exception
> handlers like ant other?
> 
> How is it done in others arch?

Have a look!

It's more like the former, except ordinarily no exceptions are passed to
the kernel if the gdb stub is included.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Exception support for i386

[Fabrice Gautier]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Subject: Re: [ECOS] Exception support for i386
> 
> Have a look!

Well, I don't understand the other archs as well as i386 so I think the more
I look the more I'm confused...

But anyway, I've read a bit of ARM code and I saw this one in hal_misc.c:
 
void
exception_handler(HAL_SavedRegisters *regs)
{
#if defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS) && !defined(CYGPKG_CYGMON)
    if (__mem_fault_handler && 
        regs->vector == CYGNUM_HAL_EXCEPTION_DATA_ACCESS) {
        regs->pc = (unsigned long)__mem_fault_handler;
        return; // Caught an exception inside stubs        
    }

    if (++exception_level == 1) __take_over_debug_traps();

    _hal_registers = regs;
    __handle_exception();

    if (--exception_level == 0) __restore_debug_traps();

#elif defined(CYGPKG_KERNEL_EXCEPTIONS)

    // We should decode the vector and pass a more appropriate
    // value as the second argument. For now we simply pass a
    // pointer to the saved registers. We should also divert
    // breakpoint and other debug vectors into the debug stubs.

    cyg_hal_deliver_exception( regs->vector, (CYG_ADDRWORD)regs );

#else

    CYG_FAIL("Exception!!!");
    
#endif    
    
    return;
}


First thing, the stuff here doesn't sound too arm specific (it's why I pick
this one...) so It could almost be the same for i386. Indeed, There is a
version of this one in the i386 hal. (Probably just because the i386 hal
derived from some other arch...)

And as I understand it the two important lines are: 

    _hal_registers = regs;
    __handle_exception();

In the i386 stub for the moment, __handle_exception is called directly.

So I have some questions about what happen in the ARM arch:

1*/ What should happen before this function is called? I've read some
comment in the arm vector.S that suggest there is some kind of stack switch.
It doesn't seems there is anything like that for i386. I suppose there are
some kind of registers backup too, and that these saved resgisters are
passed as the parameter to the exception_handler function but I can't figure
out where are those saved registers? On the stack? (btw, which stack? it
doesn't seems that the ARM asm instruction set have something about a stack
like push or pop, am I wrong?) Another point is if in the ARM arch the
context structure used by eCos (named HAL_SavedRegisters) and the structure
use by the stub/gdb are the same? It is not the case in the i386.

2*/ What does _take_over_debug_traps and _restore_debug_trap should do ?


> It's more like the former, except ordinarily no exceptions 
> are passed to
> the kernel if the gdb stub is included.

Yes, and for what i've read now an interruption that is passed to the kernel
(via cyg_hal_deliver_exception) just do a CYG_FAIL. So is there any
exception support in any arch when there is no stub?? Is the
Cyg_Exception_Control class really used in some arch??..
 
Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com