x86 c++ exception handling
karel.gardas at centrum.cz
Fri Sep 11 09:21:20 UTC 2020
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 *****
>>> 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
>>> 44 ../../../../gcc-7.5.0/libatomic/fop_n.c: No such file or
>>> (gdb) bt
>>> #0 libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at
>>> #1 0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1,
>>> #2 __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x757730)
>>> #3 __gnu_cxx::__eh_atomic_dec (__count=0x757730) at
>>> #4 __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT,
>>> at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
>>> #5 0x003ad9cb in _Unwind_DeleteException (exc=0x757770) at
>>> #6 0x003af8d0 in __cxxabiv1::__cxa_end_catch () at
>>> #7 0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116
> There is also an associated ticket:
> 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,
More information about the devel