[PATCH] samples/cdtest: Test execeptions during system init

[Chris Johns]

On 14/7/2022 4:02 pm, Sebastian Huber wrote:
> On 14/07/2022 02:31, Chris Johns wrote:
>> On 13/7/2022 6:42 pm, Sebastian Huber wrote:
>>> On 01/07/2022 12:02, Sebastian Huber wrote:
>>>> +static void early_exception()
>>>> +{
>>>> +    try
>>>> +    {
>>>> +      throw "early exception";
>>>> +    }
>>>> +    catch( const char *e )
>>>> +    {
>>>> +      rtems_test_assert(strcmp(e, "early exception") == 0);
>>>> +      throw "early exception 2";
>>>> +    }
>>>> +}
>>>> +
>>>> +static void test_exceptions_during_system_init()
>>>> +{
>>>> +    TEST_BEGIN();
>>>> +
>>>> +    try
>>>> +    {
>>>> +      early_exception();
>>>> +    }
>>>> +    catch( const char *e )
>>>> +    {
>>>> +      rtems_test_assert(strcmp(e, "early exception 2") == 0);
>>>> +    }
>>>> +}
>>>> +
>>>> +RTEMS_SYSINIT_ITEM(
>>>> +    test_exceptions_during_system_init,
>>>> +    RTEMS_SYSINIT_IDLE_THREADS,
>>>> +    RTEMS_SYSINIT_ORDER_LAST
>>>> +);
>>>
>>> Actually, on targets which use the DWARF2 unwinder (for example sparc), this
>>> doesn't work since the exception frames are no yet registered.
>>
>> Is the result a terminate with an unknown type of exception of something else?
> 
> It is a failed gcc_assert() in the unwinder code. Depending on the GCC options,
> this results in a __builtin_trap().

That is what Kinsey reported so it is the same issue. I will then see that on
the Versal which is good.

>> Kinsey is reporting an issue with aarch64 and cdtest on discord.
> 
> Yes, it seems ARM changed the exception implementation for aarch64 to use what
> everyone else uses. So we essentially have:
> 
> #if defined(__arm__)
> #define CAN_DO_EXCEPTIONS_DURING_SYSINIT
> #endif
> 

OK

>>
>> What mechanism is being used to initialise the unwinder support?
> 
> It is the C runtime initialization done during global construction.
> 

Is this then our problem?

>>
>> With libdl the unwind tables are registered as part of the loading.
>>
>>> They are
>>> registered during global construction. This also means that C++ exceptions can
>>> only be used once the global construction completed on these targets.
>>
>> Has this always been the case?
> 
> Yes, but there was no test which used the C++ exceptions during system
> initialization until recently.

Ah thanks.

>> It is part of the well documented RAII principle
>> so we need this to work.
> 
> Probably the only thing we can do is to document this constraint somewhere.

An open ticket?

Chris