public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Jonathan Larmour' <jlarmour@redhat.com>
Cc: "Ecos-List (E-mail)" <ecos-discuss@sourceware.cygnus.com>
Subject: RE: [ECOS] Exception support for i386
Date: Wed, 06 Sep 2000 18:21:00 -0000	[thread overview]
Message-ID: <8AE4B526B977D411841F00A0CC334020052C48@cuz-exchange.sdesigns.net> (raw)

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

             reply	other threads:[~2000-09-06 18:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-06 18:21 Fabrice Gautier [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-09-04 19:15 Fabrice Gautier
2000-09-05  8:49 ` Jonathan Larmour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8AE4B526B977D411841F00A0CC334020052C48@cuz-exchange.sdesigns.net \
    --to=fabrice_gautier@sdesigns.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=jlarmour@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).