[PATCH] samples/cdtest: Test execeptions during system init
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu Jul 14 06:02:55 UTC 2022
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().
> 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
>
> What mechanism is being used to initialise the unwinder support?
It is the C runtime initialization done during global construction.
>
> 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.
> 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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list