OpenBSD-portsのmtoolsを4.0.47に上げるパッチをcommitしたら、一週間もしないうちにmtools-4.0.48がリリースされました。これを受けて、portsの対応作業も済ませています。

OpenWatcomはLinux(i686)向けのバイナリを吐くことができたりしますが、Linux distro標準のコンパイラとライブラリを使っていないのに何故バイナリが動くのかと気になってしまったので調べています。結局のところ、システムコールを呼び出しているから、ということになるのでしょうか。

…だとするなら、BSD系でも似たようなことができるのかなって。

まずはELF形式の実行ファイルを処理できるかどうか雑に調べてみると、

FreeBSD

ELFヘッダのOS/ABIが9(FreeBSD)であること

NetBSD

.note.netbsd.identセクションにNetBSDのシグネチャがあること（ELFヘッダのOS/ABIはチェックしていない）

OpenBSD

.note.openbsd.identセクションにOpenBSDのシグネチャがあること（ELFヘッダのOS/ABIはチェックしていない）

DragonFlyBSD

ELFヘッダのOS/ABIも.note.tagセクションのチェックもしていないようだ

となっているようなので、この先の可能性を探るとしたらFreeBSDを使うのが良さそうです（NetBSDの場合は.note.netbsd.identセクションを作成するようwlinkを直さないといけないし、DragonFlyBSDはそもそも32bit非対応、OpenBSDは…まあいいや）。

こういうの、なんか試してみたいなーとは思ってしまうのですが実際にやるのはかなり大変なので、今のところは手を出さずに放っておくつもりです。FreeBSD Developer's HandbookのChapter 11. x86 Assembly Language Programmingとか、見ているだけでアセンブラからシステムコールを叩いてHello, world!してみたくなるんですけどね。56.1kg(23:15)

有給休暇を年間5日は消化しないといけない、とは言われていたのですが…なかなか消化する日程も立てられずにずるずるとやっていたら「有休休暇を取れ、さもなくば所属店舗変更な」ということでお休みを頂くことになりました。

という訳で、今日は20日…JMHの電波予報の日ということで受信を試みます。20-Oct-2024以来になりますね。

例によって13988.5kHzで、読めません。

JSC（共同通信社）のラジオFAXは問題なく読めるので、無線機の設定（AGCとか）による問題ではなさそうな気がしますが、なんなんでしょうかね…JSC/JMH、ともに出力5kWで鹿児島県鹿児島市からの送信となっているのに。56.5kg(22:35)

• JWasm 2.19でSvarDOSのビルドに失敗する問題はとりあえずissue立ててPR投げた
• SvarDOSのディスクイメージ作成用スクリプトをmformatベースのものに作り替える際に見つけた、mformatの問題…最終セクタにゴミが出る現象は報告した

どちらも提出してからそんなに時間は経っていないので、今のところお返事などのアクションはありません。そういえばOpenBSD-portsのmtools-4.0.27も4.0.47に上げたらどうかなーという話も反応無いっすね（バージョンを上げたら解決すると思っていたので、実際に直すためのパッチを仕込む必要があるかも）。

mformatの問題、原因を突き止めるのは随分苦労しました。セクタの最初→最後の順に書き込んでいって、最後のセクタを書く際におかしなデータを書き込むものだと思っていたのですが…実際は一番最後のセクタを書き込んでから（ここでゴミが書き込まれていた）、最初の方へシークして必要なものを書くという作りになっています。これは実デバイスでは発生せずディスクイメージ作成時でのみ発生する問題なので、気付かれていないか気付かれていてもスルーされていたのでしょう。

gdbでデバッグする際、ブレークポイントを狙ったところに張ってからrunで起動しても良いのでしょうけど、予め「ここに来た時にブレークして欲しい」という箇所にasm __volatile__("int3")を仕込んでおくと良い感じに引っかかってくれますね。こんな感じのコードで試しています（x86向けなので、arm等他のプロセッサではbkptとか適当な命令に置き換える必要があります）。多分、よく知られている話だと思いますが…今後デバッグの際に使ってみるとしましょう。55.6kg(23:45)

OpenWatcomのOpenBSD対応、できました。試作品をNetBSD上で動かして、最終的にこんな形に。試作版との違いはこんな感じ。

• コーディングスタイルをOpenWatcomに合わせている
• cc -D_POSIX_C_SOURCE=200112Lによる__BSD_VISIBLE無効化につきalloca()→malloc()/free(), getprogname()→__prognameに置き換え
• _argvがNULLであった場合への緩和策を追加（OpenWatcomのランタイムだと自動的に設定されるが、他環境ではプログラム開始時に設定する必要があり、設定を忘れていた場合に問題が起こる）
• PATH=/usr/bin:のように末端に:がある場合への対応漏れを修正（PATH=/usr/bin:.と解釈する）

結局、OpenBSDのsrc/lib/libc/gen/exec.cのように環境変数PATHの内容＋getprogname()で得られたプログラム名で総当たりと、_argv[0]をrealpath()で加工する方法にしています。今更気づいたのですが_cmdname_tokenize()、これstrsep()で置き換えられそうですね。とはいえOpenWatcomのclibには存在しないので、現状のままとします（MMDVMHostのは何かの折に直すか…？）。

さて、これでSvarDOS/edrdosのビルドができるぞーと思って早速ビルドを試みたものの…JWasm/JWasm(2.12pre)では古すぎるらしく、現在の最新版であるBaron-von-Riedesel/JWasm(2.19)でもエラーを出してしまい、進みません。2.19pre2ではビルドができているので、なんとなくこのへんの問題かなーという気がしています。少し調べてみる必要がありそうです。55.7kg(07:05)

openwatcom-v2、DragonFlyBSD, NetBSDにおいてはFreeBSDと同等な感じになるよう対応してみたのですが、自分が一番使いたいOpenBSDへの対応は、まだです。bld/watcom/c/clibext.cの_cmdname()が厄介で、

FreeBSD

もともと#if defined(__BSD__)とBSD系汎用になっていたが、sysctl()のKERN_PROC_PATHNAMEはFreeBSD, DragonFlyBSDしか対応しない。しかし共通化はせず後述の理由によりFreeBSD専用に。procfsをマウントした場合は/proc/curproc/fileのみが現在実行中のファイルに対するシンボリックリンクになる。

DragonFlyBSD

FreeBSDと同様のsysctl()を持つものの、bld/wmake/posmakeの-D_POSIX_C_SOURCE=200112Lにより__BSD_VISIBLEが無効化されるため#include <sys/types.h>を追加したところでsysctl()に必要なu_intが定義できない→UNIX汎用の処理に委ねることに。/proc/self/exe, /proc/curproc/file, /proc/curproc/exe全てに現在実行中のファイルへのリンクが張られる。

NetBSD

/proc/self/exe, /proc/curproc/exeには現在実行中のファイルへのリンクが張られるが、/proc/curproc/fileは現在実行中のファイルそのものとなる。UNIX汎用の処理で対応できるが、悪影響が出ないように修正が必要。

という訳で、この三つの環境における_cmdname()の実装はどうにかなっています。問題はOpenBSD。現在実行中のファイルの所在、それもフルパスで得る方法はおそらく無いです。argv[0]で得るにも限度がありますし、__prognameやgetprogname()はプログラム名単体になってしまいます。chromiumでも同様の問題に当たっているようで、決め打ち/環境変数でどうにかするしかなさそうな感じです。

ビルドシステム(?)で使用する、build.sh, setvars.shをまだちゃんと理解していないので、この辺りをきちっと見てからどういうコードを書くか考える必要がありそうです。なにしろ、setvars.shのOWTOOLS, OWDOSBOXを設定してbuild.sh動かせば良いんだよね程度の認識しかなくて…55.5kg(23:25)