Q:

SIGILL on std::ios_base::Init::Init() and std::string::assign(std::string const&)

Working with embedded linux cross compiling the code on an Ubuntu box to run on a COMX-p2020 module.  I'm assuming I'm either missing or have some compiler setting incorrect which is causing the illegal instruction.  Here is my compiler flags.
CPPFLAGS = -MD -MP -w -g $(DEFINES) $(INCLUDES) -pthread -mcpu=powerpc

And here is the output out put from gdb.
Program received signal SIGILL, Illegal instruction.
0x0ff1d3f4 in std::ios_base::Init::Init() () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x0ff1d3f4 in std::ios_base::Init::Init() () from /usr/lib/libstdc++.so.6
#1  0x100d3074 in __static_initialization_and_destruction_0 (__initialize_p=1,__priority=65535) at /opt/Freescale/CodeWarrior_PA_10.0/Cross_Tools/freescale-4.4/bin/../lib/gcc/powerpc-linux-gnu/4.4.1/../../../../powerpc-linux-gnu/include/c++/4.4.1/iostream:72
#2  0x100d30d0 in global constructors keyed to outDmxData() () at ../Luminaire/Mac Source/VArtnetManager.cpp:769
#3  0x100def88 in __do_global_ctors_aux ()
#4  0x10001a58 in _init ()
#5  0x100deed8 in __libc_csu_init ()
#6  0x0fc1d684 in generic_start_main () from /lib/libc.so.6
#7  0x0fc1d8b0 in __libc_start_main () from /lib/libc.so.6
#8  0x00000000 in ?? ()

It is never reaching main, looks like it is trying to allocate a global and chokes during initialization.  Here is the global in question.
unsigned char outDmxData[kNumDmxBuses][513];

I then started to strip code down to make sure I could get it to run.  I can compile and successfully run a simple hello world with same compiler settings with no problem.  I then started slowly adding objects back in till I ran into this.
Program received signal SIGILL, Illegal instruction.
0x0ff6b680 in std::string::assign(std::string const&) ()
from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x0ff6b680 in std::string::assign(std::string const&) () from /usr/lib/libstdc++.so.6
#1  0x0ff6b6e4 in std::string::operator=(std::string const&) () from /usr/lib/libstdc++.so.6
#2  0x10008014 in VxQueue::InitQueue (this=0x10052038) at ../Common/SystemObjects/VxQueue.cpp:114
#3  0x10007a6c in VxQueue::VxQueue (this=0x10052038,queueName=0x1001d580 "DestoryedObjects") at ../Common/SystemObjects/VxQueue.cpp:40
#4  0x10004aa4 in VxMessageManager::CreateQueueContext (this=0x10052008,queueName=0x1001d580 "DestoryedObjects") at ../Common/SystemObjects/VxMessageManager.cpp:209
#5  0x10004750 in VxMessageManager::VxMessageManager (this=0x10052008) at ../Common/SystemObjects/VxMessageManager.cpp:187
#6  0x10003fa0 in VxMessageManager::CreateSharedMessageManager () at ../Common/SystemObjects/VxMessageManager.cpp:36
#7  0x10001714 in main () at ../Luminaire_gcc/main.cpp:68

The line in question looks like this.
// set default queue name
char queueName[32];
snprintf(queueName, sizeof(queueName), "queue_%04d", m_queueId);
m_queueName = std::string(queueName); // <- error in question

Edit
Here is the disassembly for std::ios_base::Init::Init().  It looks like .long is the instruction it is having problems with.  Will post the std::string in a few.
   0x0ff1d3dc <+76>:    stw     r28,48(r1)
   0x0ff1d3e0 <+80>:    lwz     r24,-32768(r30)
   0x0ff1d3e4 <+84>:    stw     r31,60(r1)
   0x0ff1d3e8 <+88>:    cmpwi   cr7,r24,0
   0x0ff1d3ec <+92>:    beq-    cr7,0xff1d870 <_ZNSt8ios_base4InitC1Ev+1248>
   0x0ff1d3f0 <+96>:    lwz     r27,-32764(r30)
=> 0x0ff1d3f4 <+100>:   .long 0x7c2004ac
   0x0ff1d3f8 <+104>:   lwarx   r28,0,r27
   0x0ff1d3fc <+108>:   addi    r9,r28,1
   0x0ff1d400 <+112>:   stwcx.  r9,0,r27
   0x0ff1d404 <+116>:   bne-    0xff1d3f8 <_ZNSt8ios_base4InitC1Ev+104>

The std::string issue appears to look the same.  I'm guessing .long 0x7c2004ac means it doesn't know what the instruction is?
   0x0ff6b528 <+72>:    lwz     r0,-32760(r30)
   0x0ff6b52c <+76>:    cmpwi   cr7,r0,0
   0x0ff6b530 <+80>:    beq-    cr7,0xff6b564 <_ZNSsD1Ev+132>
   0x0ff6b534 <+84>:    addi    r10,r3,8
=> 0x0ff6b538 <+88>:    .long 0x7c2004ac
   0x0ff6b53c <+92>:    lwarx   r9,0,r10
   0x0ff6b540 <+96>:    addi    r11,r9,-1
   0x0ff6b544 <+100>:   stwcx.  r11,0,r10
   0x0ff6b548 <+104>:   bne-    0xff6b53c <_ZNSsD1Ev+92>

Edit
Sorry for the length.  More for my benefit to document this as I go.  Looks like 0x7c2004ac translates to PPC_INST_LWSYNC.  Which lead me to this article http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html that sounds like my exact problem (lwsync doesn't work on e500 processors).  The next problem being, I am strapped for time and the toolchain I'm using was packaged with the dev kit.  So I don't know of a way I can quickly patch this without trying to figure out how to build the toolchain from scratch which I know will not be a quick task, at least for me...  I guess I can contact vendor, but they have not been responsive in the past and usually it's up to me to fix their problems.

A:

Finally resolved my issue by switching to different toolchain.  I was using the toolchain that shipped with Codewarrior 10.0.2 which was causing me the issue.  I then used crosstools-ng 1.17.0 using the powerpc-e500v2-linux-gnuspe sample to build a new toolchain.  I ran into one issue where crosstools-ng failed to build gdb with [ERROR]    configure: error: python is missing or unusable.  I did have python installed, so unsure why I got the error.  I'm already cross compiling gdb myself, so just disabled it in the menuconfig (Debug Facilities->gdb).  I also had to disable -Werror on the kernel with the compiler upgrade.
Also, I am specifying e500mc for the mpcu option when compiling my binary.
CPPFLAGS = -MD -MP -w -g $(DEFINES) $(INCLUDES) -pthread -mcpu=e500mc

Thanks Jonathan for pointing me in the right direction.  Hope this helps someone debug similar issue faster than it took me.

