問題タブ [itanium]

ia64バイナリをビルドするためのg++オプションとは何ですか

実際に私は2つの質問があります：

1. SSE2の互換性はCPUの問題ですか、それともコンパイラの問題ですか？
2. CPUまたはコンパイラがSSE2をサポートしているかどうかを確認するにはどうすればよいですか？

私はGCCバージョンを使用しています：

コードをコンパイルしようとすると、次のエラーが発生します。

そしてcpuinfoこれを示した：

デバッグと移植性テストのために多数のプラットフォーム (Linux/Itanium、Max OS X/PPC など) へのアクセスを提供する UNIX シェル プロバイダを知っている人はいますか? こういうサービスがあるのはよくある問題なので、Googleで検索しても面白いものは出てこなかったのではないかと思います...

私はさまざまな CPU 上の Linux に特に興味を持っています。現在、IA64 が最も重要です。

ありがとう、S.

ここで似たようなスレッドを見つけたと思いますが、残念ながらこれは c++ に関連しているため、あまり理解できませんでした。何かをインクリメントしようとしているときにも問題が発生するようです。 `static int` をインクリメントすると SIGSEGV SEGV_ACCERR が発生する

上記のリンクを見た後、（私はそれらが似ていると感じているので）セグメンテーション違反は常に発生するわけではなく、発生はかなりまれです。ダンプは、この関数と find が呼び出されたときに発生するようです。

良い一日！コア ファイルがあり、クラッシュしたメソッドを (gdb を使用して) 逆アセンブルしたところ、以下のr44に割り当てられた値がクラッシュの原因であると言われました。

私はアセンブリに精通していないので、 0x480オフセットの意味とその値を見つける方法を尋ねたいと思い ますか?/アドレス? gdb のコア ファイルを使用します。

0x480が関数 MovePage()にあると仮定しても安全ですか?

前もって感謝します。

HP-UX Itanium プラットフォームで静的/ランタイムのメモリ リークを検出するために利用できるさまざまなツール (無料/商用) を探しています。

背景、我々: HP-UX 11.31 ia64 を使用します。しかし、すべてのアプリケーションはまだ 32 ビットのみです。C/Pro*C/COBOL のオブジェクト ファイルを含むソフトウェアと、多数のファイル/プログラムを含む非常に大きなアプリケーションを使用します。C ファイルは、標準の C コンパイラ (cc)、Oracle の proc を使用する Pro*C、および Microfocus の cob を使用する COBOL でコンパイルされます。最後に、すべてのオブジェクト ファイルを cob リンカーでリンクします。メモリ リーク/無効な参照によるコア ダンプの発生 (主に C/Pro*C コードから)

試行したこと: gdb と RTC (メモリ分析用の HP RunTimeCheck) を使用しましたが、COBOL と C が混在しているため、このツールでは重要な手がかりを得ることができません。Insure++ を使用する予定でしたが、HP-Itanium ではサポートされていないことがわかりました。現在、静的デバッグと手動出力に依存していますが、ご覧のとおり、非常に遅く効果的ではありません。

このシナリオで効果的なメモリリーク検出を行うために利用できるツール/ソフトウェアを提案してください。

前もって感謝します。

ps: Web で検索しているときに、1 つの商用ツールに出くわしましたが、使用したことはありません。http://www.dynamic-memory.com/products_Overview_htm.php

この HP-UX 11.31(IA64) で long 型と time_t 型が 4 バイト サイズであることを知って驚いています。どういうことなんですか？

私の環境：

私のコード:

time_t を aCC で 64 ビットにする方法を見つけるのを手伝ってくれる人はいますか?

現在、COBOL で記述され、OpenVMS (Integrity/Itanium) 上で実行される大規模なビジネス クリティカルなアプリケーションがあります。

月が経つにつれて、Itanium アーキテクチャの寿命についての憶測がますます増えています。もちろん、公には何も語られていませんが、このような記事やこのような記事は、憂慮すべき状況を描いています。これを裏付ける公式の情報は何も見つかりませんが、当社の廊下では、HP が OpenVMS と HP COBOL を廃止するというつぶやきさえあります。

これで私たちだけだとは信じられません。

私の見方では、いくつかのオプションがあります。

1. CHARON-VAXやCHARON-AXPなどの製品を使用して、いくつかの古いハードウェアをエミュレートし、その上でアプリケーションを実行します。私の見方では、特に 64 ビット (AXP) オプションが使用されている場合、プロセスが比較的簡単であるという利点があります。潜在的な短所は、パフォーマンスの低下です (ただし、これは、より高速なハードウェアによって相殺されるはずです)。
2. HP COBOL ベースのアプリケーションをVisual COBOLなどの最新の COBOL の方言に移植します。したがって、長所は、移植作業が比較的少ないという事実 (依然として COBOL です) と、Unix または Windows プラットフォームでアプリケーションを実行できるという事実です。短所は、COBOL を移植しているにもかかわらず、別のオペレーティング システムに移植しているという事実が問題を引き起こす可能性があることです (特に、OpenVMS 固有の依存関係がある場合)。
3. COBOL を Java のような最新の言語に自動的に変換します。これには、ハードウェア サポート、オペレーティング システム サポート、特に管理者とプログラマーの検索など、すべての従来の問題からすぐに解放されるという明らかな利点があります。これが大きな仕事であることを除けば、明白な欠点は、非慣用的な Java (または最終的に選択されたターゲット言語) になってしまうという事実です。おそらく、これは時間の経過とともに改善できるものです。
4. ゼロからの書き直し（当然、最新のテクノロジーを使用）。これを行ったことのある人なら誰でも、それがどれほど費用と時間がかかるかを知っています。リストを完全にするためにのみ含めました:)

独自の DBMS には依存しないことに注意してください。データベースは ISAM ファイルベースです。

だから...私の質問は：

選択したプラットフォームが OpenVMS と COBOL である場合、Itanium の差し迫った陳腐化に直面している他の企業は、ビジネス継続性を維持するために何をしているのでしょうか?

アップデート：

Integrity/Itanium/OpenVMS は、少なくとも2022 年まではサポートされるということを、現地の HP 担当者から公式に保証されています。これは、この問題全体がプラットフォームに関するものではなく、言語 (COBOL) に関するものであることを意味していると思います。

を介してプロセスのメモリを読み書きしたい/dev/mem。

まず、自分でコーディングした Linux カーネル モジュールを介してプロセスのメモリ マップを取得します。出力は次のようになります。

次に、Linux カーネル モジュールを介して仮想アドレス (VA) を PA に変換できます。たとえば、次のように変換できますVA:0x4000000000000008。PA:0x100100c49f8008

第三に、関数は最後のコードでread_phy_memメモリ データを取得できます。PA:0x100100c49f8008

問題: 私の問題は、text segmentPA メモリを読み取るときはすべて問題ありませんが、data segmentPA メモリを読み取る*((long *)mapAddr)と、243 行目でシステムがダウンすることです。また、試してみました

それでもシステムはダウンします。

その他の情報: 私のコンピューターは IA64、OS は Linux 2.6.18 です。システムがダウンしているとき、このようにコンソールから出力情報を取得でき、その後システムが再起動します。

関数のコードread_phy_mem

テキストセグメントはうまく機能するが、データセグメントは機能しない理由を誰でも理解できますか?

ia64 でミュール 3.1.2 を実行する必要がありますが、以下のエラーが表示されます。

許可を設定しました。必要な設定はありますか?