問題タブ [sparc]

私の gcc クロス コンパイラは、アトミック メモリ アクセスのビルトイン関数をサポートしていません。Sparc V8アーキテクチャのインラインアセンブリを使用して、次の関数を実装する方法:

これらのビルトインは、アトミックな比較とスワップを実行します。つまり、*ptr の現在の値が oldval の場合、newval を *ptr に書き込みます。

かなり変だと思うものに出くわしました。テストプログラム

出力は次のとおりです。

そこに驚きはありません。のlong intサイズは4バイトで、long longのサイズは8バイトです。ただし、longlongが割り当てられるように変更すると

コンパイル時に取得します

オプションを使用して64ビットビルドを強制すると、この同じテストが-m64コンパイルされます。私は何か間違ったことをしていますか、それともこれはGCCのバグですか？

32ビットバイナリをうまくコンパイルするネットワークIOを実行するプログラムがあります

ただし、コンパイル時に -m64 オプションを設定すると、次のやや不可解なエラーが発生します。

私のプログラムでこのエラーを引き起こしている私のソースコード operation_networkio.cc の問題のある行は

誰かが私が間違っていることとこれを治す方法を教えてもらえますか? Solaris sparc で GCC を使用しています

私が理解していることから、SPARCでは、32ビット整数量は単一のレジスタに格納され、64ビット整数量は隣接するレジスタペアに格納され、偶数レジスタには上位32ビットが含まれ、奇数レジスタには下位32ビットが含まれます。

64 ビット整数のダブルワード ペアを処理する特殊な SPARC インライン アセンブリ マクロ (インライン アセンブリ関数でも問題ありません) をいくつか作成する必要があります。私のインラインアセンブリのペアの半分。私のアセンブリ マクロは、以下に示す MULTIPLY() マクロよりも少し複雑になりますが、乗算の例が機能する場合は、64 ビットのダブルワード ペアの 2 つの半分を処理する方法を示します。MULTIPLY() マクロを修正する方法を教えてもらえますか?

それが問題になる場合に備えて、私は...

bash-2.03$ uname -a
SunOS [...] 5.8 Generic_117350-39 sun4u sparc SUNW、Ultra-80

これが私の簡単なサンプルプログラムです（Cで）：

でコンパイルするとgcc-3.2-sun4u/bin/gcc -o mult -mcpu=ultrasparc mult.c、次の出力が生成されます。

gccの出力を調べたところ-S -fverbose-asm、結果レジスタ (偶数) の奇妙なシフトと、隣接する奇数レジスタへの書き込みが行われています。私の問題は、拡張 asm 構文で隣接する奇数レジスタを一般的に参照する方法がわからないことです。おそらく 'h' asm 制約が"=h"(r)関係しているのではないかと思いましたが、使用方法の例が見つかりません。

コンパイルして、私のLinuxボックス（Ubuntu）とx86とx64の両方の他のLinuxボックスで実行しますが、SunOS Generic_142900-02 sun4u sparc unixボックスでは、回線でクラッシュします

バスエラーが発生しました。また、GCC -Gでコンパイルすると、GDBはデバッグシンボルを見つけることができません。

コードは次のとおりです。

まず第一に、私は専門家ではないので、自分自身を説明しようとして間違いがあった場合はご容赦ください。

Sparc を使用して、SPARC マシン用の外部 Linux モジュールをクロスコンパイルしようとしていますLinux-GCC-4.4.2。Linux カーネルのバージョンは2.6.36.4-00037-g059aa91-dirty. LEONプロセッサからのいくつかのファイルでパッチが適用されています。ビルド フローが提供されており、 、 、および が使用されてLinuxBuildいBuildrootますBusybox。32ビットOSを作ろうとしています。

すべてが機能しているように見えますが、モジュールをコンパイルして SPARC システムに insmod しようとすると、次のエラーが発生します。

このエラーは~/linuxbuild-1.0.3/linux/linux-2.6-git/arch/sparc/kernel/module.c 、完全を期すためにメソッド全体を提供します:

したがって、デフォルトのケースが私が該当するケースであることを理解しています。ELF_R_TYPE(rel[i].r_info(SPARC Relocations) タイプは私の~/linuxbuild-1.0.3/dist/buildroot/build-br/staging/usr/include/elf.hファイルで定義されており、一部は次のとおりです。

したがって、再配置 6 はR_SPARC_DISP32別名PC相対 32 ビットに対応します。これはmodule.ccase ステートメントで定義されていますが、64 ビット セクションでのみ定義されています。再配置を自分で書くか、必要な再配置フラグを見つけて、コンパイル中にフラグを変更する必要があると思います。再配置コードで何が起こっているのかよくわかりません。これを修正する方法を教えてください。システムを壊すように見えるので、OS を 64 ビットとしてビルドすることはできないと思います。別の解決策を見つけるのを手伝ってください。

ループの最適化を実行しようとしていたプログラムがあります。これは C++ で記述され、gcc を使用してコンパイルされています。

最終的にプロファイラーを使用して、ループの実行時間の半分以上を次の行まで追跡しました

long unsigned int 型のループ インデックス nn を除いて、この行のすべてが double 型です。

long unsigned int から double へのキャストは、プロファイラーがフラグを立てたアセンブリ命令 fxtod を生成します

テストとして、行から nn への参照を削除したため、unsigned int から double へのキャストが削除され、Ultrasparc IV で約 12 の浮動小数点演算を実行するループで、ループの実行時間がほぼ半分に短縮されました。プロセッサ。Ultrasparc II でも同様であることを確認しましたが、

int から double へのキャストが、浮動小数点の乗算は言うまでもなく、キャッシュ ミスよりもはるかにコストがかかるのは正常ですか? もしそうなら、他の人は通常それについて何をしますか?

nn のすべての可能な値のルックアップ テーブル (この場合、既知の制限された範囲がある) は、これよりも高速です。

私は最近、SUN Sparc の「サーバー」を「攻撃」してバッファ オーバーフローを引き起こすプログラムを作成するプロジェクトを終了しました。目標は、基本的に、実行中の「サーバー」内から /bin/ksh を起動することでした。

最終的には機能しましたが、愚かな理由だと思いました.ユーザーがバッファとオフセット値を引数として入力した場合は機能しませんでしたが、値がハードコードされている場合は機能しました.

「厳格な」プログラムは次のとおりです。

そして、これが「柔軟な」バージョンです。

唯一の違いは、BUFSIZE と OFFSET を定義せずに宣言し、メインで設定することです。

後世のために、私が攻撃している「サーバー」は次のとおりです。

これらはすべて、私の Oracle Solaris 10 9/10 s10s_u9wos_14a SPARC マシンでコンパイルされました。

私の質問は：

BUFSIZE と OFFSET コマンド ライン引数を作成したからといって、柔軟なプログラムが機能しないのはなぜですか?

こんにちは私は私が書いたこのC関数をアセンブリコード（SPARCアーク）に変換しようとしていますが、セグメンテーション違反（コアダンプ）エラーが発生し続けます。この関数は、文字列を長い値に変換することになっています。私はそれをテストし、すべてのテストに合格したので、C関数を正しく実行したことを知っています。これが私が変換しようとしているC関数です。

これが私が書いたアセンブリコードです。

プログラムをデバッグしましたが、strtol関数を呼び出すとセグメンテーション違反が発生します。何が間違っているのかよくわかりません。パラメータを正しく渡していると思いますが、それでもエラーが発生します。ああ、私のメインでは、FILE * StdError = stderrのように宣言されており、fprintfにパラメーターとしてstderrを渡します。

どんな助けでも適用されるでしょう。

Solaris 8 Sparc に Java 1.6.0.31 をインストールしましたが、次のコマンドを入力すると:

インストールの何が問題になっていますか?