Home/ Questions/Q 9146783
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T10:49:44+00:00

Working with embedded linux cross compiling the code on an Ubuntu box to run

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0