VM

前回見つけてしまったlemの不具合２題、早速修正して頂いた。素早い対応に感謝です。ありがとうございました。これで心置きなくlemを使えるぞ。

人様の家を訪ねてしまう問題は、sbclのソースが無かった為。

ros install sbcl --without-install

を実行した後で、 ros update lem して、lemをdumpし直せばよい。

/home/sakae/.roswell/src/sbcl-1.5.9/contrib/asdf/uiop.lisp
  (DEFUN UIOP/RUN-PROGRAM:RUN-PROGRAM)
  (DECLAIM UIOP/RUN-PROGRAM:RUN-PROGRAM
         NOTINLINE)

こんな風に、sbclのソースを参照出来るようになる。もう一件の問題 M-x gtags-defineitions.listも方も

installAntRegex                                        ant.c:24
AntParser                                              ant.c:32
EXIT_OK                                                argproc.c:35
EXIT_ERR                                               argproc.c:36
 :

ちゃんと参照出来るようになってた。良かった々。

doas

またまた、前回の枕に書いたOpenBSD発祥のdoas（日記ですから、ずっと時系列なんです）。リナに入れる時staticリンク大事って書いた。でも、本家のやつを確認したらダイナミックリンクだった。

ob$ ldd /usr/bin/doas
/usr/bin/doas:
        Start    End      Type  Open Ref GrpRef Name
        15b21000 35b24000 exe   1    0   0      /usr/bin/doas
        0058e000 205a0000 rlib  0    1   0      /usr/lib/libc.so.95.1
        056f3000 056f3000 ld.so 0    1   0      /usr/libexec/ld.so

そんな事で宜しいのでしょうか？ Teo親分って聞く前に、少しは考えてみろよ。

オイラーがスタチック案を主張したのは、ライブラリィーを改変されて悪用されないかを心配したからだ。

でも親分は、使ってるライブラリィーは微々たるものだし、重点監視物になってるよ。パッチが出ればすぐに適用出来るしね。スタティックだと、そうなってる物を洗い出して、個別にパッチが必要。面倒、忘れるって心配があるぞ。

ob$ doas syspatch
doas (sakae@ob.my.domain) password:
Get/Verify syspatch66-009_mesaxlo... 100% |*************|  1728 KB    00:00
Installing patch 009_mesaxlock
Get/Verify syspatch66-010_libcaut... 100% |*************| 17685 KB    00:08
Installing patch 010_libcauth
Get/Verify syspatch66-011_xenodm.tgz 100% |*************| 40528       00:00
Installing patch 011_xenodm
Get/Verify syspatch66-012_suauth.tgz 100% |*************|  7224       00:00
Installing patch 012_suauth
Get/Verify syspatch66-013_ldso.tgz 100% |***************|   262 KB    00:00
Installing patch 013_ldso
Get/Verify syspatch66-015_ftp.tgz 100% |****************| 58144       00:00
Installing patch 015_ftp
Get/Verify syspatch66-016_ripd.tgz 100% |***************| 38893       00:00
Installing patch 016_ripd
Errata can be reviewed under /var/syspatch

久しぶりにパッチ確認したら、随分とあったな。面白そうなのを見てみるか。(qemu on debian)

ob$ less 66-012_suauth/012_suauth.patch.sig

OpenBSD 6.6 errata 012, December 8, 2019:

A user can log in with a different user's login class.
  :

/usr/bin/su って、とっても大事なやつじゃん。binaryが更新されてた。libcとかlibcryptみたいな大事なやつも、勿論更新される。

ob$ tar ztvf 66-012_suauth/rollback.tgz
-r-sr-xr-x  1 root     bin          19280 Dec  4 09:30 usr/bin/su

そして、rollback出来るようにもなってた。無色透明。その点はリナ系のやつ分かりづらいんだよな。apt upgrade で、どうなったかの確認が面倒（オイラーが単に知らないだけかもしれないけれど）。

更に特典として、大事なライブラリィーとカーネルは、再起動の度に、オブジェクトファイルが、ランダムに再配置されるから、大幅にセキュリティの耐性が向上するよとな。

doasの記事では、FreeBSDにportされてる奴を解説、次はdebianで試してからCentOSに移って移植。オイラーと性向がそっくりだな。著者は、昔OpenBSDを使った事が有るそうで、その時にdoasを知ったとか。今は使っていないのでしょうか？もったいない事です。

[sakae@fb /usr/ports/security/doas]$ cat pkg-descr
This is the FreeBSD port of the OpenBSD "doas" command. The doas program
allows a regular user to run commands as another user (usually root). The
doas command is a simplified (hopefully more secure) version of the "sudo"
command and offers an easier to read/modify configuration.

WWW: https://github.com/slicer69/doas/

FreeBSDの一番の利点は、豊富なportsの提供にある。何処かのリナみたいに、右往左往しなくても、こういう具合に源流へさっと到達出来る事ね。

まあ、リナのぬるま湯でまったりするのもいいけどね。でも、知らないうちにアナコンダとやらに、じわっと締め殺されるぞ。長いものには巻かれろとは古人の戒め。

MicroPython

用心用心、火の用心って事で、少しアナコンダにあがらってみますかね。かわゆい奴と言う事で、IoT関係では重宝されてるとか。簡単に言うとrubyに対するmrubyです。クリスマスプレゼントは大きい程嬉しい、、、訳でもないよね。

MicroPython

[sakae@fb /tmp]$ cd micropython-1.12
[sakae@fb /tmp/micropython-1.12]$ cd ports/unix/
[sakae@fb /tmp/micropython-1.12/ports/unix]$ gmake
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosit
y.
mkdir -p build/genhdr
gmake: python3: Command not found
gmake: *** [../../py/py.mk:232: build/genhdr/mpversion.h] Error 127

ln -s python3.6 python3

[sakae@fb /tmp/micropython-1.12/ports/unix]$ gmake
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
GEN build/genhdr/qstr.i.last
/bin/sh: gcc: not found
gmake: *** [../../py/mkrules.mk:76: build/genhdr/qstr.i.last] Error 127
gmake: *** Deleting file 'build/genhdr/qstr.i.last'

FreeBSDはgccと縁を切ったのよ。世の中そういう方向だよねと呟きながらMakefileを眺める。

# On OSX, 'gcc' is a symlink to clang unless a real gcc is installed.
# The unix port of MicroPython on OSX must be compiled with clang,
# while cross-compile ports require gcc, so we test here for OSX and
# if necessary override the value of 'CC' set in py/mkenv.mk
####ifeq ($(UNAME_S),Darwin)
ifeq ($(UNAME_S),FreeBSD)
ifeq ($(MICROPY_FORCE_32BIT),1)
CC = clang -m32
else
CC = clang
endif

取り合えずFreeBSDもDarwinの仲間って事で。いや違うな。元祖がFreeBSDで分家がDarwinでしょ。あちらは、独自言語を強く推してるけどね。iphoneとかの母言語として。

 :
CC ../../lib/utils/printf.c
mpy-cross not found at /tmp/micropython-1.12/mpy-cross/mpy-cross, please build i
t first
gmake: *** [../../py/mkrules.mk:103: build/frozen_content.c] Error 1

先にやる事が有るとな。で、場所を移したらやはりgcc攻撃が有ったぞ。clang使えやとなだめすかしてみたら、

CC ../py/frozenmod.c
CC main.c
CC gccollect.c
LINK mpy-cross
ld: error: unknown argument: -dead_strip
ld: error: unknown emulation: ap
ld: error: cannot open mpy-cross.map: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [../py/mkrules.mk:146: mpy-cross] Error 1

unknown argumentの対策したけど、emulation: apが相変わらず出て来る。そんなのFreeBSDのclangには無いんだろうね。力が尽きた。こういう時はportsに頼り切りになるのが楽でしょう。

  :
Proceed with this action? [y/N]: y
[1/1] Fetching micropython-1.5.1_3.txz: 100%  167 KiB 170.6kB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing micropython-1.5.1_3...
[1/1] Extracting micropython-1.5.1_3: 100%
=====
Message from micropython-1.5.1_3:

--
===>   NOTICE:

The micropython port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be removed in
the future. To volunteer to maintain this port, please create an issue at:

https://bugs.freebsd.org/bugzilla

More information about port maintainership is available at:

https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port

誰も蛇なんて嫌いだから、世話したく無い。で、飼育員を絶賛募集中とな。蛇を飼うならリナの所へ行け。そして、絞め殺されろ。お前、pythonに恨み有るんか？

[sakae@fb ~]$ micropython
MicroPython v1.5.1 on 2019-11-15; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> 1 + 1
2

Makefileの一部

LIB_DEPENDS=    libffi.so:devel/libffi
USES=           gmake pkgconfig python:3.4+,build readline shebangfix

必要品にgccが列挙されてるかと思ったら、要請されていないなぁ。頑張ればclangな環境でもコンパイル出来るのかな。特にパッチを当ててる風でも無いし。。。昔のmicropythonは、粗削りで、面倒な事は要求してなかったのかな？暇なら試してみろよ。

ESP32

MicroPythonのportsの全体像。

debian:ports$ ls
bare-arm/  esp8266/     nrf/       qemu-arm/  teensy/   zephyr/
cc3200/    javascript/  pic16bit/  samd/      unix/
esp32/     minimal/     powerpc/   stm32/     windows/

eps32って石は、CQ出版が出しているインターフェース誌によく取り上げられているな。ラズパイは日経Linuxが扱っているんで、棲み分けしてるんだな。

何でも、電源入れるだけでpythonのreplが動き出すっていう今風な作りなんだな。昔々、NECが出してた国民機PC8801だったかは、電源ONでbasicが動くと言う偏ったパソコンだった。

それって、コンピューターちゃうで、単なるbasic機、絶対に買うもんかと思っていたよ。そしたら、眼の付け所が違うシャープが、クリーンコンピューターと銘打ってMZ-80を出してきた。これだと思って、即飛びついたのは懐かしい思い出だ。

今は小さな基盤に載ったpythonがshellを兼ねてる訳ね。ちと、石の事を調べてみる。

EPS32 OverView

Technical Reference Manual

Datasheet

IoT開発スタートブック ── ESP32でクラウドにつなげる電子工作をはじめよう！

どうも載ってるCPUの事が詳しく出てこないなあ。

Xtensa®Instruction Set Architecture

このあたりかな。カスタマイゼーション可能なRISCプロセッサーらしい。余りローレベルな部分の資料が無いのは、みんなpythonレベルで満足しちゃってるからだな。なんだかつまんないぞ（と、元ハード屋さんが嘆いています）

VM

そんな訳で、身近な人が設計・製作・保守をしてるバーチャルマシンを覗いてみる事にします。石がハードで出来ていようとソフトで出来ていようと、まず知りたいのは、プログラマーから見えるレジスターが、どんな構成になってるかですね。

レジスタ

そして命令セット

VMインストラクション

非常に有名な石だものだから、よってたかってリバースエンジニアリングされて、丸裸にされています。

VM インストラクション一覧

そしてこちらでは、その用例が命令毎に出てました。

VMのスタック操作 (未完)

設計者自らが語っています。

toy VM

その石を使って、自作しようと言う試みも。

以下は、合わせて読みたい、貴重な資料

Scheme処理系 Gauche の最適化まとめ前編

第4回大人のためのブラックボックス読解講座

matz/shiroさん、ご出演の良記事。

debian:tmp$ gosh  -fno-inline
gosh> (disasm (lambda (x) (* x 3)))
CLOSURE #<closure (#f x)>
=== main_code (name=#f, cc=0x23a000, codevec=0x124580, size=4, const=0 stack=1):signatureInfo: ((#f x))
     0 LREF0-PUSH               ; x
     1 CONSTI(3)
     2 NUMMUL2                  ; (* x 3)
     3 RET

gosh> (use gauche.vm.insn )
gosh> (class-slot-ref <vm-insn-info> 'all-insns)

at git

古いgaucheを再現出来るかな？ gitしたやつで試してみる。

(base) sakae@debian:Gauche$ git tag
  :
release0_9_6
release0_9_7
release0_9_8
release0_9_9
snapshot0_7_3_pre1
stack_gc_0_4_3
vmptr_experiment0_8_8

ちゃんとtagが打ってあった。tagってcommitのエイリアス？よう分からん。

(base) sakae@debian:Gauche$ git show release0_8_3
commit fb5c720ebdf2857b61baf28c2c1be2a7c3953d9d (tag: release0_8_3)
Author: Shiro Kawai <shiro@acm.org>
Date:   Thu Dec 2 23:47:13 2004 +0000

    This commit was manufactured by cvs2svn to create tag 'release0_8_3'.
  :

時代は15年も前。よく飽きずに続いているものだ、超感心します。

(base) sakae@debian:Gauche$ git checkout release0_8_3
Note: checking out 'release0_8_3'.
  :

古い時代にワープします。

(base) sakae@debian:Gauche$ ./DIST gen
  :
patching file gc/configure
Hunk #1 FAILED at 793.
1 out of 1 hunk FAILED -- saving rejects to file gc/configure.rej

configureの作成の所で齟齬をきたしている。gcも時代と共に進化してて、対応出来なくなってるんだな。残念至極。

昔shiroさんが書いていたけど、ソースが有れば、昔を再現出来るってのは幻想なんですね。実感しましたよ。

気を取り直して原始のgoshの所まで行ってみる。

debian:Gauche$ git show initial
commit f3d6de8450b889b56c2e71833d3b53c9262c069f (HEAD, tag: initial)
Author: Shiro Kawai <shiro@acm.org>
Date:   Thu Jan 11 19:26:04 2001 +0000

Top-dirに、有るのはこれだけ

debian:Gauche$ ls
doc/  gc/  src/

srcの下にMakefileが有ったのでコンパイルしてみると、謎のsnowってschemeが必要と言われた。今のgoshで代用出来ないかな？

debian:src$ make
gosh genstub stdlib.stub
*** ERROR: cannot find "textutils" in ("/usr/local/share/gauche-0.97/site/lib" "/usr/local/share/gauche-0.97/0.9.9/lib")
    While compiling "./genstub" at line 12: (require "textutils")
    While loading "./genstub" at line 12
Stack Trace:
_______________________________________
make: *** [Makefile:20: stdlib.c] Error 70

やっぱり駄目である。資料が無いかと探してみたら

snow

先人の苦労話が出てきた。リンクを辿ってみたけど、ことごとくNot Foundである。

後は、得意のもぐら叩き戦法で、genstubを今のgoshで動くように改造しちゃうって手があるな。冬休み（いえ、何時も休みなんだけど）の宿題って言うか内職にどうだ！

今年の更新はこれで終了です。来年も宜しくお願い致します。