こんにちは、川合です。 I.Tak. さんは 2002/10/28 18:57:23 の「[OSASK 5233] obj2bimt」で 書きました： > obj2bim2がcoffに対応していない(win32専用)なのはケシカランと思った >ので、coffに対応させたバージョンを作ってみました。 >http://user.ecc.u-tokyo.ac.jp/~g240845/osask/ > > ソースだけですけど、windowsを使っている人たちはcoffなんて使わない >に違いない……ということで、バイナリなしです。ではー 先ほどダウンロードして、ソースとドキュメントを読ませていただき ました。なるほど、どういうことになっているのか、大体分かりました 。ありがとうございます。 僕としては、「win32のCOFFもどき」よりもピュアなCOFFの相対ラベ ル記述の方が好きです。そう、僕がもし独自にオブジェクトファイル形 式を設計するとしたら、ピュアなcoffと同じにしたでしょう。あれこそ 正常なセンスというものです（まあ、COFFもどきだと0x00000000という バイト列が頻繁に出るようになるので、圧縮するときに圧縮率が上がる というメリットはありますが）。 で、僕は自動判別型両対応のobj2bim3を開発したいと望んでいるので すが、どうやって判別すればいいでしょうか？（僕が読んだ限りでは、 obj2bimtはピュアCOFF専用のようだと思ったんですが、そうですよね？ それとも両用になっていますか？？？・・・いや、両用にはなっている けど、これは危険じゃないですか？それについては後述）。 COFFもどき（＝win32）では、セクションヘッダのflagsが、 .text : 0x20 ?? ?? 0x60 .data : 0x40 ?? ?? 0xc0 .bss : 0x80 ?? ?? 0xc0 となっているみたいなんですが、この部分はピュアではどうなっている でしょうか？この0x20、0x40、0x80という値はピュアでももどきでも共 通のようですが上位の0x60、0xc0というのは差違があるんじゃないかと 思っています。どうでしょうか？ これに限定せず、もし自動判別に使える情報があったら教えてくださ い。URLでもいいです。・・・と言いつつ探していたら、関連情報を見 付けました。Googleのキャッシュなので長ったらしいですがすみません 。 http://www.google.co.jp/search?q=cache:_hi14d_nKS8C:giscenter.icc.ru:8082/scripts/WWWBinV.dll/ShowR%3Fcoff.rfi+common+object+file+format&hl=ja&ie=UTF-8&inlang=ja これによると、マイクロソフトがflagsにつけた意味は次のようになっ ているようです。 bit 0 : リザーブ(TYPE_DSECT) bit 1 : リザーブ(TYPE_NOLOAD) bit 2 : リザーブ(TYPE_GROUP) bit 3 : リザーブ(TYPE_NO_PAD) bit 4 : リザーブ(TYPE_COPY) bit 5 : セクションはコードを含む bit 6 : セクションは初期済みデータを含む bit 7 : セクションは未初期化のデータを含む bit 8 : リザーブ(LNK_OTHER) bit 9 : セクションはコメントもしくはその他のデータを含む bit10 : リザーブ(TYPE_OVER) bit11 : Section contents will not become part of image. bit12 : Section contents comdat. bit13 : リザーブ bit14 : Reset speculative exceptions handling bits in the TLB entries for this section. bit15 : Section content can be accessed relative to GP bit16 : MEM_SYSHEAP bit17 : MEM_PURGEABLE bit18 : MEM_LOCKED bit19 : MEM_PRELOAD bit20-23 : アライン設定(上記ページによると、デフォルトは16バイ トアラインだそうです) bit24 : セクションは拡張リロケーションを含む bit25 : セクションは無効である。 bit26 : セクションはキャッシュ不能である。 bit27 : セクションはページング可能ではない。 bit28 : セクションは共有可能である。 bit29 : セクションは実行可能である。 bit30 : セクションはリード可能である。 bit31 : セクションはライト可能である。 つまり、COFFもどきである限り、bit29-bit31はそれなりにセットさ れると仮定して良さそうです。.textならbit29が、.dataや.bssでは、 少なくともリードは許可されるでしょう。 一方、ピュアなCOFFの仕様は、以下のページで見付けました。 http://osr5doc.ca.caldera.com:1997/topics/COFF_SectHdrFlags.html bit 0- 4 : セクションタイプ 0x00 : レギュラーセクション 0x01 : ダミーセクション 0x02 : ノーロードセクション 0x04 : グループ化されたセクション 0x08 : パディング用セクション 0x10 : コピーセクション 他の値については、おそらくリザーブ bit 5 : セクションはコードを含む bit 6 : セクションは初期済みデータを含む bit 7 : セクションは未初期化のデータを含む bit 8-15 : 拡張セクションタイプ(ここが非零の場合はbit0-15全体 でセクションタイプを示すらしい) 0x0200 : コメントセクション 0x0400 : オーバレイセクション 0x0800 : .libのためのセクション(リンカはこれをコメントセクシ ョン扱いせよ) そんでもって、上位16bitについては特に規定していないようです。 ということで、bit29-31が000ならピュアなCOFFで、非零ならCOFFも どきと解釈することにします。 それで先に飛ばしたobj2bimtの危険性についてですが、それは call external_symbol+10 みたいな場合も call external_symbol のように処理してしまうという意味で危険だと思ったんです。まあ、確 かにそういうケースはめったにないかもしれませんが。 それと以前に2ちゃんねるでobj2bimがリードオンリーデータを捨てて しまって困るという書き込みがあったのですが（Part2の512さんです） 、今回やっとリードオンリーがどのように記述されるのか分かったので obj2bim3でサポートできそうです（というか下位8bitだけでセクション を判定することにします）。今日中にリリースします。 それでは。 -- 川合 秀実(KAWAI Hidemi) OSASK計画代表 / システム設計開発担当 E-mail:kawai !Atmark! imasy.org Homepage http://www.imasy.org/~kawai/