2025年2月のてきとーな日記

［不意のお休みを頂いてしまったので］

有給休暇を年間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)