使用嵌入式Linux交叉编译Ubuntu盒上的代码,以便在COMX-p2020模块上运行。我假设我要么丢失,要么编译器设置不正确导致非法指令。这是我的编译器标志。
CPPFLAGS = -MD -MP -w -g $(DEFINES) $(INCLUDES) -pthread -mcpu=powerpc
这是从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 ?? ()
它永远不会到达main,看起来它正在尝试在初始化期间分配全局和扼流圈。这是全球性问题。
unsigned char outDmxData[kNumDmxBuses][513];
然后我开始剥离代码以确保我可以运行它。我可以使用相同的编译器设置编译并成功运行一个简单的hello world,没有任何问题。然后我开始慢慢地添加对象直到我遇到这个。
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
有问题的行看起来像这样。
// set default queue name
char queueName[32];
snprintf(queueName, sizeof(queueName), "queue_%04d", m_queueId);
m_queueName = std::string(queueName); // <- error in question
修改
这是std :: ios_base :: Init :: Init()的反汇编。看起来.long是它遇到问题的指令。将std :: string发布在几个。
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>
std :: string问题看起来看起来一样。我猜.long 0x7c2004ac
意味着它不知道指令是什么?
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>
修改
抱歉这个长度。为了我的利益,我可以随时记录下来。看起来像0x7c2004ac转换为PPC_INST_LWSYNC。这让我想到这篇文章http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html听起来像我的确切问题(lwsync在e500处理器上不起作用)。接下来的问题是,我被困在时间和我正在使用的工具链与开发工具包打包。所以我不知道如何在不试图弄清楚如何从头开始构建工具链的情况下快速修补此问题,我知道这不是一项快速的任务,至少对我而言......我想我可以联系供应商,但他们过去没有回应,通常由我来解决他们的问题。
答案 0 :(得分:1)
使用gdb命令disassemble
查看第0帧中的指令,然后查明这是否是硬件平台的合法指令。
答案 1 :(得分:0)
最后通过切换到不同的工具链解决了我的问题。我正在使用Codewarrior 10.0.2附带的工具链,这导致了我的问题。然后我使用powerpc-e500v2-linux-gnuspe样本使用crosstools-ng 1.17.0来构建一个新的工具链。我遇到了一个问题,其中crosstools-ng无法使用[ERROR] configure: error: python is missing or unusable
构建gdb。我确实安装了python,所以不确定为什么我得到错误。我已经在交叉编译gdb了,所以只需在menuconfig(Debug Facilities-&gt; gdb)中禁用它。我还必须通过编译器升级在内核上禁用-Werror。
另外,我在编译二进制文件时为mpcu选项指定了e500mc。
CPPFLAGS = -MD -MP -w -g $(DEFINES) $(INCLUDES) -pthread -mcpu=e500mc
感谢Jonathan指出我正确的方向。希望这可以帮助某人更快地调试类似的问题。