> Where does custom_except leaves, in kernel-space or user-space ?

I have called rthal_trap_catch in the init function of the KD.
I have tried also in a rt task inside KD.

>> - KD has an rtdm interface to map the 16 MB memory on user space with
>> rtdm_iomap_to_user.
>> - UD starts and It maps with the rtdm (rtdm_iomap_to_user)
>
>This is completely useless. You can use an anonymous mapping in
>user-space, you will not need the help from an rtdm driver. And your
>mapping needs to be executable (you need to pass PROT_EXEC to mmap).
>>
>> - UD copy a binary asm x86 test fpu (some instructions to generate
>> exceptions for tests) in the 16 MB memory mapped
>
>If you do that, your binary needs to be relocatable, that is its code
>must not depend on the address at which it is loaded. Are you sure your
>binary blob has this property ?

It's a long story... I know anonymous mapping is better but I have need physical contiguos memory
(not for the test of course). The binary blob has fixed addresses between 1 to 16 MB so I have mapped the first 15 MB of the UD (starting to 1 MB). I Know it is very strange...

>>
>> - UD start the real time task
>>
>> Now here is a the problem. If I invoke an exception (int 3, floating
>> point exception and so on) outside the 16 MB mapped memory
>> "custom_except" is called ok. If the same code is invoked into the 16
>> MB mapped memory the program crash (and this is ok) reporting the
>> description of the exception in the terminal (also this is ok) but
>> "custom_except" is not called!
>
>Who reports the exception, then ?

I start UD from the terminal and the terminal always report the right error.

>Are you sure the exception reported is
>the one you expect ?

Yes, I tried floating point, debug (int 3), page fault..

>IOW, are you sure the problem is not that your
>memory mapping is not executable ?

The PROT_EXEC flag is set.
If I try to execute some instructions It works.

>> Is there something wrong using the mapped memory in this mode?
>> NOTE: I am using xenomai 2.4.0rc1 with kernel 2.6.23
>>Is this a joke ? Why choosing a release candidate of a release which
>>happened since then ? Why not using the latest stable release ?

you are right. It will be better to use the latest one (not rc). I had an already patched kernel
(with an other working xenomai application)

    Gabriele