[ECOS] suggestions regarding except1 and kexcept1 kernel tests

[ECOS] suggestions regarding except1 and kexcept1 kernel tests

[sandeep]

hi dsm/jl,

wouldn't it be better if following section of code in
except1 and kexcept1 kernel tests are moved under
"#ifdef CYGNUM_HAL_EXCEPTION_DATA_ACCESS" to cause
illegal access, as in compat/posix - signal2 test.

also, what is your view on keeping the illegal access
and unaligned access testings separate in mentioned
kernel tests (code snippet below doing both at same
time), as being done in similar posix test signal2.

-----------------
  // First try for an address exception (unaligned
access exception
    // or SEGV/BUS exceptions)
    do {
        x=*(volatile int *)(p-1);
        p+=0x100000;
    } while(p != 0);
-----------------

regards
sandeep



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] suggestions regarding except1 and kexcept1 kernel tests

[Nick Garnett]

sandeep <shimple0@yahoo.com> writes:

> hi dsm/jl,
> 
> wouldn't it be better if following section of code in
> except1 and kexcept1 kernel tests are moved under
> "#ifdef CYGNUM_HAL_EXCEPTION_DATA_ACCESS" to cause
> illegal access, as in compat/posix - signal2 test.
> 
> also, what is your view on keeping the illegal access
> and unaligned access testings separate in mentioned
> kernel tests (code snippet below doing both at same
> time), as being done in similar posix test signal2.
> 
> -----------------
>   // First try for an address exception (unaligned
> access exception
>     // or SEGV/BUS exceptions)
>     do {
>         x=*(volatile int *)(p-1);
>         p+=0x100000;
>     } while(p != 0);
> -----------------

The idea here is to try and generatate an exception of any sort. We
are not really concerned with trying to test each possible exception
source, just the kernel exception handling code. Since we don't know
what sort of exceptions the underlying hardware is capable of, we just
try a bunch of things that are likely to cause an exception. Doing the
unaligned and illegal accesses together is an optimization. If
that fails then we try an FP exception. Any target that doesn't
generate an exception for at least one of those probably won't
generate any exceptions at all.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss