Project Home
Project Home
Source Code
Source Code
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - libecpp.so.4 causes SIGILL with "lwsync" on Freescale 8572ds: (2 Items)
   
libecpp.so.4 causes SIGILL with "lwsync" on Freescale 8572ds  
SDP 6.4.0; PPC board: Freescale 8572ds

While still evaluating this Freescale board, we have come across a trivial C++ construction that causes a SIGILL 
(illegal instruction) inside library target/qnx6/ppcbe/lib/libecpp.so.4

        static int  int1 = strlen( "Blah1" );

That line by itself inside a function causes a crash that looks like this:

     Process 3321871 (testit) terminated SIGILL code=1 fltno=1 
     ip=fe38b854(libecpp.so.4@__cxa_guard_release+0x24) mapaddr=0000b854. 
     ref=00000000
     Illegal instruction (core dumped)

Please see the attached note for a minimal piece of source code that causes the problem inside a "testit.cpp" file. The 
file is compiled this way:

   qcc -V4.2.4,gcc_ntoppc  -EB -DQNX -DQNX_ppc  -Y_ecpp -o testit testit.cpp

Interestingly, if the file is renamed to a .c file, then it works fine, even though the compilation reports a warning:

DOS>  qcc -V4.2.4,gcc_ntoppc -EB -DQNX -DQNX_ppc -Y_ecpp -o testc testc.c
testc.c: In function 'strlenInStatic':
testc.c:10: warning: initializer element is not constant
testc.c:10: warning: (near initialization for 'int1')

On x86 (running a few months old 6.4.0) there is no problem.

libecpp.so.4 library is probably compiled for a non-generic PPC processor. I disassembled libecpp.so.4 and found the 
instruction call to lwsync.

0000b850 <__cxa_guard_release>:
    b850:       7c 08 02 a6     mflr    r0
    b854:       94 21 ff f0     stwu    r1,-16(r1)
    b858:       48 01 8d 7d     bl      245d4 <object_mutex+0x294>
    b85c:       93 c1 00 08     stw     r30,8(r1)
    b860:       7f c8 02 a6     mflr    r30
    b864:       90 01 00 14     stw     r0,20(r1)
    b868:       89 23 00 01     lbz     r9,1(r3)
    b86c:       39 29 ff ff     addi    r9,r9,-1
    b870:       99 23 00 01     stb     r9,1(r3)
    b874:       7c 20 04 ac     lwsync      <<<<<< ILLEGAL instruction for Freescale?

Attachment: Text notes.txt 2.79 KB
Re: libecpp.so.4 causes SIGILL with "lwsync" on Freescale 8572ds  
Fernando Gonzalez wrote:
> SDP 6.4.0; PPC board: Freescale 8572ds
> 
> While still evaluating this Freescale board, we have come across a trivial C++ construction that causes a SIGILL 
(illegal instruction) inside library target/qnx6/ppcbe/lib/libecpp.so.4
> 
>         static int  int1 = strlen( "Blah1" );
> 
> That line by itself inside a function causes a crash that looks like this:
> 
>      Process 3321871 (testit) terminated SIGILL code=1 fltno=1 
>      ip=fe38b854(libecpp.so.4@__cxa_guard_release+0x24) mapaddr=0000b854. 
>      ref=00000000
>      Illegal instruction (core dumped)
> 
> Please see the attached note for a minimal piece of source code that causes the problem inside a "testit.cpp" file. 
The file is compiled this way:
> 
>    qcc -V4.2.4,gcc_ntoppc  -EB -DQNX -DQNX_ppc  -Y_ecpp -o testit testit.cpp
> 
> Interestingly, if the file is renamed to a .c file, then it works fine, even though the compilation reports a warning:

> 
> DOS>  qcc -V4.2.4,gcc_ntoppc -EB -DQNX -DQNX_ppc -Y_ecpp -o testc testc.c
> testc.c: In function 'strlenInStatic':
> testc.c:10: warning: initializer element is not constant
> testc.c:10: warning: (near initialization for 'int1')
> 
> On x86 (running a few months old 6.4.0) there is no problem.
> 
> libecpp.so.4 library is probably compiled for a non-generic PPC processor. I disassembled libecpp.so.4 and found the 
instruction call to lwsync.

gcc will only emit lwsync from the sync_lock_release atomic builtin. The 
lwsync you're hitting is added by inline assembly in the libstdc++ 
atomicity routines (in libsupc++). When you rename it to a .c, it gets 
compiled as a c program and __cxa_guard_release is never executed.

I've filed PR 63792. Please contact our support department to request an 
official patch. Or I can make available an experimental fix in the 
meantime if you'd like.

Regards,

Ryan Mansfield