HP OpenVMS Systems Documentation |
| 前へ | 次へ | 目次 | 索引 |
モジュール名がパス名に含まれていると,モジュールのシンボル・テーブルがデバッガによって自動的にロードされるようになりました。以前は,たとえば SET BREAK M\R などのコマンドでは,モジュール M のシンボルがロードされていないと,"unknown symbol R" で失敗していました。本バージョンでは,デバッガはまずモジュール M のシンボルをロードし,次にシンボル R を見つけるようになったため,このコマンドは成功します。
5.4.11 C++ デストラクタのサポートの強化
C++ のデストラクタ名がデバッガで認識されるようになりました。以前は,ユーザがデストラクタ名を %NAME レキシカルで囲む必要がありましたが,これは不要になりました。以下の例に新しい動作を示します。
DBG> examine C::~C
C::~C: alloc r35 = ar.pfs, 3F, 01, 00
DBG>
DBG> ex/source ~C
module CXXDOCEXAMPLE
37: ~C() {}
|
5.4.12 C++ テンプレート名のサポート
C++ のテンプレート名がデバッガで認識されサポートされるようになりました。以下に例を示します。
DBG> e Map<string, int>::operator[] Map<string, int>::operator[]: alloc r34 = ar.pfs, 1E, 05, 00 |
デバッガで,Ada で記述されたプログラムが部分的にサポートされるようになりました。デバッガは,パッケージ,子ユニット,プロシージャ,変数,単純なデータ型,モジュール型など,ほとんどの Ada 構造を理解します。タグ付きの型や制約なし配列へのポインタなど,より複雑なデータ型は,将来のリリースでサポートされる予定です。
5.5 Kerberos for OpenVMS
Kerberos Version 3.0 for OpenVMS は,MIT Kerberos V5 Release 1.4.1 を基にしています。(Kerberos の以前のバージョンである Version 2.1 は, MIT Kerberos V5 Release 1.2.6 を基にしていました。)
Kerberos Version 3.0 の新機能を以下に示します。
http://web.mit.edu/kerberos/historical.html |
Kerberos は,従来の (共有秘密鍵) 暗号方式を使用し,信頼できる第三者の認証サービスとして認証を実行します。 Kerberos は,プリンシパルの身元を確認する手段を提供しますが,ホスト・オペレーティング・システムによる認証に頼らず,ホスト・アドレスの信用にも基づいていません。また,ネットワーク上のすべてのホストの物理的なセキュリティが不要で,ネットワーク内でやり取りされるパケットは自由に読み取り,変更,挿入ができるという前提に立っています。クライアントとサーバが Kerberos を使用して身元を証明した後は,すべての通信を暗号化して,プライバシとデータの一貫性を確保することができます。
詳細は,『HP Open Source Security for OpenVMS, Volume 3: Kerberos』を参照してください。
最新版の Kerberos for OpenVMS をダウンロードする方法については,次の Web サイトを参照してください。
http://h71000.www7.hp.com/openvms/products/kerberos/ |
Kerberos についての詳細は,次の場所にある MIT Kerberos の Web サイトを参照してください。
http://web.mit.edu/kerberos/www/ |
C,C++,Ada などのコンパイラで生成されたオブジェクト・モジュールでは,シンボル・テーブル中のシンボルが変更されている可能性があります。これは,一般に「マングル化」と呼ばれます。これらの名前はリンカが参照する際のシンボル名であり,シンボルを解決するためにリンカが使用します。
マングル化を行う理由としては,プログラミング言語のオーバロード機能や,一意に名前を短縮する必要性が挙げられます。このようなモジュールをリンクし,シンボル未定義のメッセージが表示された場合は,リンカはオブジェクト・モジュールのシンボル・テーブルから取り出したシンボル名 (つまり,マングル化された名前) だけを表示します。このように処理されるため,未定義のマングル化されたシンボルとソース・コードのデマングル化された名前を照合するのが難しくなります。そのため,表示名情報 (DNI) を生成する将来のコンパイラをサポートするために,リンカは表示名情報を処理できるようになりました。また,リンカはソース・コード名を表示します。つまり,リンカは未定義のシンボル名をデマングル化することができます。さらに,ユニバーサル・シンボル (つまり,共用可能イメージからエクスポートされるシンボル) にデマングル化情報がある場合,リンカは生成される共用可能イメージにその情報を含めることができます。
シンボル解決処理は変更されていません。リンカは引き続きシンボル定義のマングル化されたシンボル名を使用してシンボル参照を解決します。シンボル・ベクタ・オプションも変更されておらず,これまでと同様に,名前 (マングル化された名前) がシンボル・テーブルに見つかる必要があります。
新しいコマンド行修飾子 /DNI を使用して,デマングル化情報の処理を制御することができます。リンカに対してシンボル名のデマングル化を許可し,作成する共用可能イメージに,必要なデマングル化情報を格納するには, /DNI (省略時の指定) を指定します。以下の場合には /NODNI を指定します。
グローバル・シンボル定義の変換テーブルが格納された新しいマップ・セクションを要求することができます。このテーブルは,マングル化されたシンボル名とデマングル化されたシンボル名を関連付けます。デフォルトでは,リンカはマップ・ファイル内にこのセクションを生成しません。このセクションの生成を要求するには, /FULL 修飾子にキーワード DEMANGLED_SYMBOLS を指定します。 /FULL 修飾子の他のキーワードと同様に,/MAP 修飾子を指定します。最後に,/DNI 修飾子を指定します。マップ中の変換テーブルは,シンボル・ベクタのエントリを確認するのに役立ちます。
以下の例 (編集済み) は,デマングル化された名前がリンカのメッセージ内に表示される様子を示したものです。
$ cre foo.cxx
extern double foo (int) ;
double bar (void) { return foo (123); }
[Ctrl/Z]
$ cxx foo
$ link foo
%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-I-UDFSYM, CXX$_Z3FOOI1RLFMIE
%ILINK-W-USEUNDEF, undefined symbol CXX$_Z3FOOI1RLFMIE referenced
source code name: "double foo(int)"
section: .text
offset: %X0000000000000020 slot: 2
module: FOO
file: DISK$USER:[JOE]FOO.OBJ;1
$
|
デマングル化情報のセクションは,オブジェクト・モジュールまたは共用可能イメージの一部です。シンボル名をデマングル化するために必要な情報は,すべてそのセクションに含まれているか,その情報のデマングル化を行うファシリテータ・ルーチン名と共用可能イメージ名が含まれます。この共用可能イメージは,通常は SYS$LIBRARY にあり,すでに OpenVMS 上にある言語の実行時環境によって提供されるか,言語コンパイラをインストールする際に提供されます。ファシリテータ・ルーチンが必要になると,リンカはイメージを起動してルーチンを呼び出します。ルーチンが共用可能イメージになかったり,イメージが見つからない場合など,いずれかの時点でこれに失敗すると,リンカは問題を示す情報メッセージを表示します。リンク操作は,デマングル化情報の共用可能イメージへの格納と同様に,ファシリテータ・ルーチンの呼び出しの成否とは無関係です。
5.7 ライブラリアンを使用したデマングル化された名前とマングル化された名前の一覧表示 (I64 のみ)
LIBRARY コマンドに /DEMANGLED_SYMBOLS 修飾子が追加されました。この修飾子を使用すると,ライブラリアンは ELF オブジェクトまたは ELF 共用可能イメージ・ライブラリ内の,言語プロセッサによって変更されたシンボル (マングリングと呼ばれます) と,それに対応するデマングル化された名前 (つまり,ソース・コードに記述されている名前) の一覧を表示します。マングル化された名前は,オブジェクト・モジュールの外部シンボル (または共用イメージのユニバーサル・シンボル) として出力されます。言語プロセッサが名前をマングル化する理由の 1 つは,C++ 言語の機能である関数のオーバロードです。
ライブラリアンは,オブジェクト・モジュールまたは共用可能イメージから取り出したシンボルを保存します。これらのシンボルには,マングル化されたシンボルが含まれています。これらのシンボル名をデマングル化するために必要な情報と,それに役立つ共用可能イメージの名前が,オブジェクト・モジュールまたは共用可能イメージに格納されています。
ELF オブジェクト・ライブラリの場合は,オブジェクト・モジュールは完全にライブラリに格納されます。デマングル化情報を取得するために,オブジェクト・モジュールがメモリにマップされ検索されます。場合によっては,言語固有のデマングル化共用可能イメージもメモリにマップされて起動されます。シンボルはオブジェクト・ライブラリ・モジュールから読み込まれ,モジュールで提供される情報を使用してデマングル化されます。オブジェクト・ライブラリ・モジュールのどのシンボルがライブラリのシンボル名テーブルにあるかを示すために,ライブラリのシンボル名テーブルが検索されます。以降のモジュールも同様に処理され,一覧が生成されます。
ELF 共用可能イメージ・ライブラリの場合は,共用可能イメージはライブラリに格納されません。これは OpenVMS Alpha および OpenVMS VAX の共用可能イメージ・ライブラリと似ています。ただし,エクスポートされたシンボルとその他の最小限の情報だけがライブラリに格納されます。そのため,ライブラリアンは,デマングル化情報を取得するために,ライブラリの外部にある共用可能イメージを検索します。
ライブラリアンは 3 段階の検索を行います。この検索は,ファイルを正しく取得できると停止します。
従来からある /OUTPUT= 修飾子を使用して,デマングル化処理で生成された出力を任意の指定したファイルに出力することができます。 /OUTPUT= 修飾子を指定しないと,ライブラリアンは省略時の指定として現在のディスクおよびディレクトリに,ライブラリのファイル名と同じ名前で,ファイル・タイプが .LISのファイルに処理結果を出力します。
従来からある /ONLY= 修飾子を使用すれば,デマングル化で選択されるライブラリ・モジュールを限定することができます。
たとえば,オブジェクト・ライブラリのデマングル化されたシンボルを表示し,出力を端末画面に送るには,コマンド行プロンプトで次の DCL コマンドを入力します。
$ LIBRARY /DEMANGLED_SYMBOLS /OUTPUT=SYS$OUTPUT OBJLIB.OLB |
次の例では,共用可能イメージ・ライブラリ SHAREIMG.OLB のデマングル化されたシンボルを,ファイル DUMP.LIS に出力します。
$ LIBRARY /DEMANGLED_SYMBOLS /OUTPUT=DUMP.LIS SHAREIMG.OLB |
次の例では,共用可能イメージ・ライブラリ SHAREIMG.OLB のデマングル化されたシンボルを,省略時のファイル指定 SYS$DISK:[]SHAREIMG.LIS に出力します。
$ LIBRARY /DEMANGLED_SYMBOLS SHAREIMG.OLB |
次の例では,オブジェクト・ライブラリ OBJLIB.OLB 内のオブジェクト・モジュール MY_OBJ のデマングル化されたシンボルを,省略時のファイル指定 SYS$DISK:[]OBJLIB.LIS に出力します。
$ LIBRARY /DEMANGLED_SYMBOLS /ONLY=MY_OBJ OBJLIB.OLB |
5.8 OpenVMS Alpha システム用の HP MACRO コンパイラ
MACRO コンパイラは,Alpha システム用の最新の GEM バックエンドを使用するようにアップグレードされました。また,以下に示すいくつかの機能拡張も行われています。
5.9 RMS (Record Management System) の機能拡張
ここでは,OpenVMS Version 8.3 におけるRMS の機能拡張について説明します。
| 前へ | 次へ | 目次 | 索引 |