1

COMX-p2020 モジュールで実行するために、Ubuntu ボックスでコードをクロス コンパイルする組み込み Linux を使用します。私は、私が行方不明であるか、不正な命令を引き起こしているコンパイラ設定が間違っていると仮定しています。これが私のコンパイラフラグです。

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 ?? ()

メインに到達することはありません。初期化中にグローバルとチョークを割り当てようとしているようです。これが問題のグローバルです。

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 プロセッサでは動作しません)。次の問題は、時間に追われており、使用しているツールチェーンが開発キットにパッケージ化されていることです。そのため、少なくとも私にとっては簡単な作業ではないことがわかっているツールチェーンをゼロから構築する方法を理解しようとせずに、これにすばやくパッチを当てる方法がわかりません...ベンダーに連絡できると思います。しかし、彼らは過去に反応がなく、通常、彼らの問題を解決するのは私次第です.

4

2 に答える 2

1

gdb コマンドdisassembleを使用して、フレーム 0 の命令を確認し、それがハードウェア プラットフォームで有効な命令かどうかを調べます。

于 2013-01-16T00:25:43.117 に答える
0

最後に、別のツールチェーンに切り替えることで問題を解決しました。Codewarrior 10.0.2 に同梱されているツールチェーンを使用していたため、問題が発生していました。次に、powerpc-e500v2-linux-gnuspe サンプルを使用して crosstools-ng 1.17.0 を使用し、新しいツールチェーンを構築しました。crosstools-ng が gdb のビルドに失敗するという 1 つの問題に遭遇しました[ERROR] configure: error: python is missing or unusable。私はpythonをインストールしていたので、なぜエラーが発生したのかわかりません。私はすでにgdbを自分でクロスコンパイルしているので、menuconfigで無効にしました(デバッグ機能-> gdb)。また、コンパイラのアップグレードに伴い、カーネルで -Werror を無効にする必要がありました。

また、バイナリをコンパイルするときに mpcu オプションに e500mc を指定しています。

CPPFLAGS = -MD -MP -w -g $(DEFINES) $(INCLUDES) -pthread -mcpu=e500mc

正しい方向に向けてくれたジョナサンに感謝します。これが、誰かが同様の問題を私よりも早くデバッグするのに役立つことを願っています.

于 2013-01-18T23:19:47.970 に答える