KOF2015 emacs 18.59 and mule 1.1 on NetBSD 7.0

KOF2015 関西オープンソースの「BSDなひととき」のセミナーで発表した
「emacs 18.59 / mule 1.1 を NetBSD 7.0 で動かした話」
のスライドです。

Transcript

1. emacs 18.59 / mule 1.1 を NetBSD 7.0 で動かした話 関西オープンソース2015 謎アプリ on 謎マシン Izumi Tsutsui tsutsui@NetBSD.org
2. Emacs 使ってますか？
3. 最新版は 24.5
4. ・1992年10月リリース （LUNA-II発売の翌年） ・emacs18 の最終版 emacs 18.59 とは
5. 今でもダウンロードできます https://ftp.gnu.org/old-gnu/emacs/
6. Emacs 18 antinews http://www.dennougedougakkai-ndd.org/alte/1ste/emacs/elisp-manual-19-2.4-jp2.0/elisp-jp_45.html
7. MULti-lingual Enhancment to GNU-Emacs mule 1.x は emacs18 を ベースに多言語化したもの mule とは
8. なぜ mule 1.1なのか • 某サークルの386BSD機に入ってた • 機能的にあんまり困ってなかった • Emacs19で動かない *.el があった • 1996年頃のNetBSD 1.2でも ビルドできてしまった • NetBSDの後方互換性が高過ぎて 気がつくと20年近く経っていた
9. 1998年製バイナリ https://twitter.com/tsutsuii/status/566608838267138051
10. Yet another emacs18 user https://twitter.com/Chris_J_Baird/status/566596051042185216
11. 復活の機運(?) https://twitter.com/tsutsuii/status/566617110042775552
12. とりあえず 適当にいじって gentooパッチを マージしてみる
13. なんとなく動きました https://twitter.com/tsutsuii/status/570284256338927617
14. X11term版が動かない問題 • 通常のターミナル版は動く • X11term版は起動後固まる？ ⇒read(2)から帰ってこない • とりあえずいろいろ読んでみる
15. /* 92.7.10 modified for Mule Ver.0.9.5 by T.Enami In compile_pattern(), set bufp->buffer to 0 for forcing re_compile_pattern() to alloc (not realloc) it. In set_pattern(), last_regexp is set to Qnil. */ https://twitter.com/tsutsuii/status/571003158199021569
16. えなみさん とは • 某サークルの先輩に当たる方 • 某曽田さんと同年代 • NetBSDデベロッパ • mule初期からいろいろと パッチ送っていたり
17. https://twitter.com/tsutsuii/status/571403457875161088
18. 4時間後
19. https://twitter.com/_enami/status/571469622001577984
20. 中略
21. https://twitter.com/_enami/status/571487238321647616
22. ( ﾟдﾟ) https://twitter.com/tsutsuii/status/571487878192054272
23. NetBSD/i386 では復活 https://twitter.com/tsutsuii/status/571518589108293632
24. 一部修正してluna68kでもOK https://twitter.com/tsutsuii/status/575336006292934657
25. amd64ではダメっぽい https://twitter.com/tsutsuii/status/576445070624186368
26. ふたたびえなみさん https://twitter.com/_enami/status/576454331299291136
27. Lisp_Object とは • 整数、ポインタ、その他の 内部値を保持する整数型 • emacs 18 では int型で定義 • mule 1.1は alpha OSF/1対応で long型でも定義できるように なっている？
28. int vs long 問題 Lisp_Objectを longにした場合 以下の問題が発生する • 関数プロトタイプ宣言が不完全 ⇒返り値が暗黙的に int になる ⇒LP64では Lisp_Object の 上位32ビットが失われる
29. https://twitter.com/_enami/status/576515850233995265
30. ( ﾟдﾟ) https://twitter.com/tsutsuii/status/576550741055156225
31. 個別に見てても 終わらないので 片っ端から プロトタイプ宣言 を追加
32. 作業結果 https://twitter.com/tsutsuii/status/577167362266263552
33. 修正行数 https://github.com/tsutsui/mule1.1-netbsd/commit/cb7f46b0ced6a3860f292c893ded76d3010b346e
34. ついでに オリジナルの emacs 18.59 も amd64対応 https://twitter.com/tsutsuii/status/578972091342401536
35. LP64対応の次は
36. https://twitter.com/tsutsuii/status/658325284463054848
37. というわけで sparc64 (LP64BE) です
38. 初回トライ結果 https://twitter.com/tsutsuii/status/578230868579225600
39. mule固有部分で 落ちているので、 オリジナルの emacs 18.59でも トライしてみる
40. 超微妙動作 なにコレ(´・ω・｀)
41. よくわからんので 関数宣言を K&R⇒ANSI にして警告出るか 試してみる
42. 修正行数 https://github.com/tsutsui/emacs-18.59-netbsd/commit/402435325b01dd9d95bc975ea1905a046dd5cfe2
43. 作業結果 https://twitter.com/tsutsuii/status/658229468532596736
44. もう少し真面目に調べてみる • "*invalid*” の条件を確認 ⇒Lisp_Object の型情報が変 • i386で同じ変数の変化を確認 ⇒値が変化する関数を特定 • その関数を見てみると……
45. ポインタキャストの罠？ for (offset = (char *)&buffer_local_flags.name - (char *)&buffer_local_flags; offset < sizeof (struct buffer); offset += sizeof (Lisp_Object)) /* sizeof int == sizeof Lisp_Object */ if (*(int *)(offset + (char *) &buffer_local_flags) > 0 || *(int *)(offset + (char *) &buffer_local_flags) == -2) *(Lisp_Object *)(offset + (char *)b) = *(Lisp_Object *)(offset + (char *)&buffer_defaults); Lisp_Objectっぽい領域に intでアクセスしている。 明らかにクサい https://github.com/tsutsui/emacs-18.59-netbsd/blob/0a7383dcb7b9dbc863fa4adf6c7ae3330ec551d5/src/buffer.c#L270
46. とりあえず (Lisp_Object *) のキャストに修正
47. 超微妙動作2 ちょっと進んだ？
48. 他のソースにも 同様のキャストが あったので 同じく修正
49. https://twitter.com/tsutsuii/status/658311797850542081
50. amd64では動いて sparc64では動かない ケース （LP64BE問題）
51. LP64LEでの動作 (LSB) 02 00 00 00 00 00 00 00 (MSB) 64ビットのLisp_Objectを 32ビットの (int *) でアクセスした場合、 先頭から4バイトの値を読み 32ビット整数として返す ⇒4バイトに収まる整数なら同じ値になる Lisp_Object (1) = 2 Lisp_Object (2) = 0 (LSB) 00 00 00 00 00 00 00 00 (MSB)
52. LP64BEでの動作 (MSB) 00 00 00 00 00 00 00 02 (LSB) Lisp_Object (1) = 2 0 Lisp_Object (2) = 0 (MSB) 00 00 00 00 00 00 00 00 (LSB) 64ビットのLisp_Objectを 32ビットの (int *) でアクセスした場合、 先頭から4バイトの値を読み 32ビット整数として返す ⇒上位4バイト側が返るので違う値となる
53. まとめ • コンパイラの警告は大事です • プロトタイプ宣言は重要です • 機種に依存しない記述が大事です • 調べて推測通りに動くと楽しい！