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.

For example if I compile this test

#include <stdatomic.h>

int add(atomic_int *i, int v)
{
        return atomic_fetch_add(i, v);
}

on my Linux machine, I get:

gcc -O2 -S -o - test.c -m32
        .file   "test.c"
        .text
        .p2align 4,,15
        .globl  add
        .type   add, @function
add:
.LFB0:
        .cfi_startproc
        movl    4(%esp), %edx
        movl    8(%esp), %eax
        lock xaddl      %eax, (%edx)
        ret
        .cfi_endproc
.LFE0:
        .size   add, .-add
        .ident  "GCC: (SUSE Linux) 7.5.0"
        .section        .note.GNU-stack,"",@progbits

There is no call to libatomic.



_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to