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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel