AB開発日記

いっちまいました。HDDが。電源をつけても、HDDがカチャカチャ音を立てて、起動不可能な状態。

とはいっても、壊れたのはメインマシンではなく、9月まで使っていたお蔵入り寸前のPC。新しいのに切り替えた直後なので、このタイミングにはビックリしてしまいます。

もしも、作業データを新PCに移す前にいってしまっていたら…

こう考えると、コワイですね〜。HDDが壊れるって初めての体験です。本当にあるんですねぇ〜こんなこと。明日は我が身ですよ！皆さん。バックアップはちゃんとしましょう。おいらも、ブログをカキながら作業データをUSBメモリーにコピーっと。

この壊れたPC、おいらが高校生のときに自作した愛着があるマシンです。自作をしながら細かいことは忘れてしまったのですが、たしか、こんな感じだったと…

• Athlon 1GHz
• RAM 256MB
• HDD 60GB + 10GB
• FDD
• CD-ROM
• DVD-RAM
• Windows 2000 / NT4.0 / 98

グラフィックとかサウンドとかは特にすごくはなかったのですが、5インチベイが賑やかっす。トリプルブートという環境が、パソコン好きであることを匂わせてます。

まぁね・・・

このマシンがなければAB1〜AB4は、登場しておらなかったことと思います。

本だって、このマシンのお陰で書き終えることができました。

9月までは、Webサイト製作とかも、すべてこのマシンで…。

おいらの高校生活、大学生活がギッシリとつまったマシンなだけに、お疲れさん、と言ってやりたいです。

などという、ちょっと高等テクニックを駆使しながら、デバッガを作り続けております。

先日もお話したとおり、デバッグターゲットの64アプリは、32デバッガからCreateProcessすることができません。厳密にいうと、起動はできるのですが、ブレークポイントや例外処理が不可能な状態であり、32デバッガ＆64アプリでは事実上、デバッギングはできません。

そーしますと、単純に32デバッガを改良して64デバッガを新たに作成せよ！ということになるのですが、こいつはちょっと無理な注文なんですよ。デバッガを64ビットへ移植するということは、デバッグ情報を処理する機構もすべて移植の対象として扱わなければなりません。こんな面倒な作業、今やっとるヒマはないんです。

これを解決するのがモニターアプリ。32デバッガとターゲットの64アプリを繋げてくれるアプリケーションです。

と、まぁ、ここまでが先日までのお話。ここからはモニターアプリが実際にどうのよな感じで動くのか、デバッガとの情報のやり取りはどのようになるのかを紹介していきます。まずは、出てくるアプリを整理してみましょう。

• 32デバッガ（BasicCompiler.exe） … AB4にもくっついておる、お馴染のプロセスデバッガ。コンパイラと同居している。
• 64モニター（monitor64.exe） … 32デバッガから呼び出され、デバッギングループを担当。ターゲット64アプリとのダイレクトなやり取りを実現。
• ターゲット64アプリ … AB x64 Compilerが吐き出す、正真正銘のネイティブ64プログラム。こいつを何とかしてデバッグしてやりたいのだ！

デバッガとターゲットアプリの間にうまい具合にモニターアプリをかみ合わせてしまえば、あたかも、32ネイティブで動くデバッガからデバッギングしているように見えます。もちろん、既存のデバッグ情報処理機構は32デバッガのそれを流用。効率も良いです。

32デバッガと64モニターとの情報のやり取りは、匿名パイプとメールスロットを使います。

• 32デバッガ … メッセージ読み取りループ
• 64モニター … 事実上のデバッギングを行い、デバッグメッセージを32デバッガに垂れ流す

※読み取りと垂れ流しは、同期的に行います。

64モニターから32デバッガへ送るデータが非常に多いことから、匿名パイプはそういう方向で用意します（匿名パイプは双方向できないんで…）。逆方向へは、メールスロットでも使います。

こうやって、32デバッガと64モニターが密にやり取りをすることで、64アプリをデバッグできるようになるんです。

と、ここまで仕組みをお話しましたが、まだ実装作業が済んでいません。64モニターなんかはAB x64 Compilerで作るので、形ができあがってきたら、非公式のこの場でそのプログラムをご紹介してみます。ご期待あれ（といっても、ちょっと分野偏りすぎか？？？）

f(–;;;それにしても、こんなことを試している人間は、世界でどれだけいるんだか。

そんなこんなで、今日はとうとうオヤツをコンビニへ買いに行く以外、外出はありませんでした。こういう日があと二日も続いたら…おいらの頭の中はどうなってしまうかわかりません。

まぁ、来週月曜は元バイト仲間達とさっそく飲む予定になっておるので、それまでがんばりやす。

いきつけの喫茶店、コパンに、数ヶ月ぶりにお邪魔しました。ちょ〜オシャレなこの店、後日、画像をアップロードしたいところです☆

phpBBに[hide]タグを追加してみました。以前から、長いソースコードをベタッと貼り付けると記事が見づらくなるというご意見をいただいていたので、これでちょっとは解消されるハズです。

もし、[window]タグなるものがあったら、こっちのほうが使いやすいのかな…？どうでしょう？？

一週間、悩みに悩んだGetThreadContext。本日、やっとその真相が明らかになりました。

Declare Function GetThreadContext Lib "kernel32" (hThread As HANDLE, ByRef lpContext As Any) As Long

この関数でターゲットアプリのレジスタの内容を取得することは、10/28にお話しましたね。第一パラメータにスレッドハンドルを、第二パラメータにCONTEXT構造体を指定するのですが・・・

よ〜く考えてみてください。

・32ビットアプリのHANDLE型 … DWORD（※4バイト）

・64ビットアプリのHANDLE型 … QWORD（※8バイト）

これでは、32デバッガから64アプリをデバッグできないわけです。だって、32ビットデバッガが持ち合わせる64アプリスレッドのハンドルはサイズが足りないんですから。

なんでこんな初歩的な問題に気づかなかったんでしょうかね。デバッガ内でターゲットアプリのハンドルを扱う部分はほぼ全滅です。となると、新たに64デバッガを作ることに・・・

しかし、いい方法があります。デバッガの構造事態はAB4のそれを流用し、モニターアプリ（デバッギングループとターゲットアプリのメモリ読み込み処理）を別途用意してしまうという方法です。

モニターアプリは64ネイティブのものを用意しなければならないのですが、これはAB x64 Compilerで作ってしまえばいいんです。

とうとう、ここまでこました。デバッガができれば、β公開ができそうです。

最近、携帯をパカパカするたびに電源が落ちてしまうんです。ひどいときは、通話中にだって…

おいらが使っておるのはSH505i。買ってから2年半くらいが経とうとしています。それにしてもよく使ったな〜。電池との接触が悪いのか、とにかく寿命ですかね。

いよいよ通話やメールに支障がでてくるとなると、買い替えですな。お次はなににしよう…。いまさら番号は変えたくないんで、これまたドコモケータイですな。もうすぐ発売されるSH902iがちょっと気になるわ〜

最近は本気モードで開発作業をしていることから、晩酌しながらということはあまりないんです。そこで、ビールの代わりに登場したちょっといいヤツがあります。

先日、中華街へ出向いた際に、料理屋さんで出てきたおいしいお茶を買って帰ったんですよね。

そいつは中国茶「プーアル」。

日本茶とは全く違う風味を持ち合わせており、苦味というものがありません。ウーロン茶とはまたちょっと違うんだよな〜。クセが無く、とても飲みやすいっす。

10月もあと少し。このお茶で乗り切りますかぁー。

今日は一日中パソコンです。外はいい天気なのにな〜。

さてさて、ここらで気分を変えて、64コンパイラが生成したコードをデバッグするためのデバッガ造りを始めることにしたのですが、、、

初っ端から躓いております。GetThreadContext関数が正常に動作しません。この関数に渡すCONTEXT構造体は、CPUレジスタの内容を管理するデータ構造になっておるため、x86とAMD64のそれとでは内容が違います。

そこで、Microsoft Platform SDK2003から下記のような構造体を引っ張り出してきまたんです。正式にはCONTEXT構造体として定義されていますが、おいらが作業を行っているVC6ではすでに同じ名前でx86用のものが定義されています。そんな理由から、構造体名がCONTEXT64に変わっているのです。

struct CONTEXT64 {

    //
    // Register parameter home addresses.
    //
    // N.B. These fields are for convience - they could be used to extend the
    //      context record in the future.
    //

    DWORD64 P1Home;
    DWORD64 P2Home;
    DWORD64 P3Home;
    DWORD64 P4Home;
    DWORD64 P5Home;
    DWORD64 P6Home;

    //
    // Control flags.
    //

    DWORD ContextFlags;
    DWORD MxCsr;

    //
    // Segment Registers and processor flags.
    //

    WORD   SegCs;
    WORD   SegDs;
    WORD   SegEs;
    WORD   SegFs;
    WORD   SegGs;
    WORD   SegSs;
    DWORD EFlags;

    //
    // Debug registers
    //

    DWORD64 Dr0;
    DWORD64 Dr1;
    DWORD64 Dr2;
    DWORD64 Dr3;
    DWORD64 Dr6;
    DWORD64 Dr7;

    //
    // Integer registers.
    //

    DWORD64 Rax;
    DWORD64 Rcx;
    DWORD64 Rdx;
    DWORD64 Rbx;
    DWORD64 Rsp;
    DWORD64 Rbp;
    DWORD64 Rsi;
    DWORD64 Rdi;
    DWORD64 R8;
    DWORD64 R9;
    DWORD64 R10;
    DWORD64 R11;
    DWORD64 R12;
    DWORD64 R13;
    DWORD64 R14;
    DWORD64 R15;

    //
    // Program counter.
    //

    DWORD64 Rip;

    //
    // Floating point state.
    //

    union {
        XMM_SAVE_AREA32 FltSave;
        struct {
            M128A Header[2];
            M128A Legacy[8];
            M128A Xmm0;
            M128A Xmm1;
            M128A Xmm2;
            M128A Xmm3;
            M128A Xmm4;
            M128A Xmm5;
            M128A Xmm6;
            M128A Xmm7;
            M128A Xmm8;
            M128A Xmm9;
            M128A Xmm10;
            M128A Xmm11;
            M128A Xmm12;
            M128A Xmm13;
            M128A Xmm14;
            M128A Xmm15;
        };
    };


    //
    // Vector registers.
    //

    M128A VectorRegister[26];
    DWORD64 VectorControl;

    //
    // Special debug control registers.
    //

    DWORD64 DebugControl;
    DWORD64 LastBranchToRip;
    DWORD64 LastBranchFromRip;
    DWORD64 LastExceptionToRip;
    DWORD64 LastExceptionFromRip;
};

↑ハァ〜長いです。

で、実際にスレッドごとのCPUレジスタの内容を取得するには、下記のようなコードで実現できます。

CONTEXT64 Context;
Context.ContextFlags=CONTEXT_ALL64;
GetThreadContext(hThread,(LPCONTEXT)&Context);

実現できるはずなのですが、いくらやってもGetThreadContextの戻り値は1が帰るのに、肝心の構造体が書き換わりません。なんででしょ〜？？？

かれこれ、この問題に3時間も費やしております。いい天気なのに・・・

このブログをご覧の皆さんはもうお気づきかと思いますが、ここ3〜4日、64コンパイラの開発が進んでおりませんハイ。遊んでおります・・・

要所要所で少しでも作業を…と思いつつの3〜4日だったのですが、やはり、友達が来てしまうと集中力は1/10になりますな。まぁ、こんなおいらに付き合ってくれる連中は大事にしたいので、作業バカにはならないように気をつけなきやならんです。

さっそく、最近の作業内容をチョロッとお話します。

まず、本日64コンパイラ試作版及び次期バージョンのVer4.11に搭載される新しいディレクティブの追加作業を行いました。

• #ifwin64
• #ifwin32
• #endif

C/C++のヘッダライブラリの様子を知っている方はもうピンとこられたかと思いますが、32/64コンパイラ独特のコードを同一のソースコード内に記載することができます。

これらのディレクティブが搭載されると、何がよいかって？

簡単なことです。32/64コンパイラがインクルードファイルを共用しやすくなるからです。たぶん、これから複雑化していくインクルードファイル郡には欠かせない存在ですな。

例えば、実行環境に左右される基本型を32/64コンパイラを意識せずに一つのファイルで定義できるようになります。

#ifwin64
TypeDef LONG_PTR =  Int64
TypeDef ULONG_PTR = QWord
#ifwin32
TypeDef LONG_PTR = Long
TypeDef ULONG_PTR = DWord
#endif

↑こういうことです。

今日は司法人カトーさんと静岡へ出かけました。目的は、カトーさん宅から見つかった古銭を鑑定してもらうことです。古銭を扱っている店をネットで調べると、なにやら明文堂という書店（！？）がよくヒットしたんで、そこへ行くことに。

古銭の世界ではおなじみの大正時代の1円玉や、寛永通宝、天保通宝などがたんまりと入った木箱を大事に抱えてのお出かけです。

明文堂、静岡市の浅間神社の近くにある、一応書店なんだと思います。フィギュアや古銭、切手などがところ狭しと店内に並んでおります。

店に入ると、ご主人が出てくるのですが、おっさんを見た瞬間、おいらの頭の中でなにかが直結しました。

このおっさん、どっかで見たことあるぞ・・・

そう、何を隠そう、この明文堂は地元のローカル番組に計4回も出ておるんです。ちょっと前に静岡まるごとワイドで見た顔がそこにはありました（ちょいびっくり）。

早速カトーさん持参の古銭を鑑定してもらうことになるのですが、なんといってもこのおっさんの鑑定スピードの速いこと…

おっさん「これは2000円だな。こっちは、うーん、500円ってとこかな。」

おいら・カトーさん「・・・・・」

おっさん「いいよ、これら全部、○○円で引き取るよ。ホラ、もってきな」

五分も経たないウチにアッサリと鑑定は終わりました。金のやり取りもスピーディー（というか、あり得ないくらいお気軽）なんですよ。このおっさんは領収書というものをしっておるのでしょうか。まぁ、かなりオイシイ キャラをしております。今度、古い掛け軸とかが見つかったらこのおっさんのところに持っていきたいね〜、なんて、カトーさんとおいらは上機嫌で店を後にしました。