x86 c++ exception handling

[Karel Gardas]

On 9/11/20 11:12 AM, Sebastian Huber wrote:
> On 11/09/2020 10:48, Heinz Junkes wrote:
> 
>> Here is a mail I received from a colleague.
>>
>> It concerns thereby an "old" problem which seemed already solved?
>>
>> FYI. I can run the unit tests, but I'm seeing a couple of hangs.
>> The first I'm looking at is epicsTimeTest which seems to be
>> related to c++ exception handling.  I recall that there were
>> problems with x86 exception handling, but I also recall hearing
>> that this was fixed.
>>
>> ...
>>> ***** Starting EPICS application *****
>>> 1..212
>>> ok  1 - epicsTime_gmtime() for EPICS epoch
>>> ok  2 - nanosecond overflow throws
>> ... hangs ...
>>
>> Attaching debugger shows:
>>
>>> Program received signal SIGINT, Interrupt.
>>> libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at
>>> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
>>> 44      ../../../../gcc-7.5.0/libatomic/fop_n.c: No such file or
>>> directory.
>>> (gdb) bt
>>> #0  libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at
>>> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
>>> #1  0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1,
>>> __mem=0x757730)
>>>     at
>>> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:49
>>>
>>> #2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x757730)
>>>     at
>>> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:82
>>>
>>> #3  __gnu_cxx::__eh_atomic_dec (__count=0x757730) at
>>> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_atomics.h:72
>>> #4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT,
>>> exc=0x757770)
>>>     at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
>>> #5  0x003ad9cb in _Unwind_DeleteException (exc=0x757770) at
>>> ../../../../gcc-7.5.0/libgcc/unwind.inc:271
>>> #6  0x003af8d0 in __cxxabiv1::__cxa_end_catch () at
>>> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_catch.cc:125
>>> #7  0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116
>>> (gdb)
> 
> There is also an associated ticket:
> 
> http://devel.rtems.org/ticket/2830
> 
> I think the i386 BSPs need to be cleaned up to use an instruction set
> which fits current the x86 hardware. I mean hardware which is still in
> use and not some stuff from the 1990s.
> 

If I'm not mistaken, then this is simply fixed by using other BSP's
variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
and gcc's lib provides necessary synchronization functions then...

Please correct me if I'm wrong,

Thanks,
Karel