The Man Who Fell From The Wrong Side Of The Sky:最新 5 日分

2019/8/24(Sat)

○[p**src] パッケージ同士の無駄な依存関係

毎度のことなんだがperlのバージョンが5.28から5.30になったことでp5-*の不整合が発生してめんどくさいのだが、今回はほとんど再インストール級の作業になってしもうた。

ちなみにperlは5.30.0で後方互換だいぶ切り捨てたのだけどその話ではない、そこいらへんはチラシの裏もしばらく前に対策しとったのでな…

なぜ再インストール級の作業な羽目に陥ったかというと、それはオレオレN6環境は

という状態だからなのよね。

この設定だと

という深い依存関係があって、lang/gcc8までさかのぼってアンインストールする必要があるのだ。 なもんでlang/gcc8をアンインストールするには今度はlibstdc++も消えるので依存するパッケージも消さんとならんのでドミノ倒しどころか壊滅状態なのだ。 ちゅーことでワイは諦めてそっと/usr/pkgごと消した(/usr/pkg/etcのバックアップは忘れないようにね！)

つーかそもそもopensslもperlに依存(RUN_DEPENDS)しとるのが判断ミスよな。 

USE_TOOLS+=             fgrep gmake makedepend perl:run

これConfigure/configスクリプトの実行に必要なBUILD_DEPENDSで十分なんですわ。

おそらくこれってc_rehashとCA.plちゅーperlスクリプトのためだけにRUN_DEPENDしとるんだろうけど、こいつらbaseではperl無いこともあって使われてないのよね。 なのでbinに入れる必要もp**src的にはあまりなく、baseと同様にshare/openssl以下に放り込んどけばいいだけよね(CA.plの方はMakefile修正してそうなっとるのだが、c_rehashの方は修正漏れなんだろうか)。

どうしてもbinに入れたいってのであればopenssl-libとopensslでパッケージ分割すりゃいいわけでな。 それに今後perl5本体に同梱されるライブラリがopenssl依存になったりすると循環参照になる可能性も無いわけではないのでな、こういう本質的でない依存関係は持つべきじゃないのだ。

そしてもうひとつ、gcc8がpython37(とgsed)に依存(RUN_DEPENDS)してる理由がさっぱりなのですわ、Makefileを確認してみると 

.include "../../lang/python/application.mk"

とmake実行時にshebangをpkgsrcでインストールしたpythonに置換するREPLACE_PYTHONというマクロを定義したファイルをインクルードしている。

なのでgcc8と一緒にpythonに依存したスクリプトがインストールされると推測されるわけだが、これを確認してみると 

maintainer-scripts/branch_changer.py
gcc/ada/doc/share/conf.py
gcc/ada/doc/share/latex_elements.py
gcc/ada/doc/share/ada_pygments.py
gcc/jit/docs/conf.py
gcc/gdbhooks.py
libstdc++-v3/scripts/make_graph.py
libstdc++-v3/python/libstdcxx/v6/__init__.py
libstdc++-v3/python/libstdcxx/v6/xmethods.py
libstdc++-v3/python/libstdcxx/v6/printers.py
libstdc++-v3/python/libstdcxx/__init__.py
contrib/dg-extract-results.py
contrib/header-tools/headerutils.py
contrib/mark_spam.py
contrib/testsuite-management/validate_failures.py
contrib/gen_autofdo_event.py
contrib/check_GNU_style_lib.py
contrib/check_GNU_style.py
contrib/analyze_brprob_spec.py
contrib/update-copyright.py
contrib/analyze_brprob.py
contrib/filter_params.py
contrib/jit-coverage-report.py
libffi/generate-darwin-source-and-headers.py

いくつかのpythonスクリプトがヒットするんだけど、分類すると

とどう考えてもBUILD_DEPENDSで問題無さそうなシロモノばっかりなんよね。 もしgccでC/C++ソースをビルドする際にバックエンドでこれらのスクリプトが動くならRUN_DEPENDSである必要あるけど、そうでないならこちらも本質的でない無駄な依存関係でしかない。

ということで、lang/python/application.mkから更にインクルードされてるlang/python/pyversion.mkにあるマクロ 

# PYTHON_FOR_BUILD_ONLY
#       Whether Python is needed only at build time or at run time.
#
#       Possible values: yes no test tool
#       Default: no

の定義忘れだよなこれ。

これ以外にもperl関連のパッケージにおいてはテストの実行にしか必要の無いパッケージがRUN_DEPENDSになってたりするのが多くてほんともうちょっと何とかならんのか。 まぁこれは元のMakefile.PL自体が間違えててテスト時以外は不要な依存関係を定義してたりするのを丸写しだったりするんだけどね…

2019/8/20(Tue)

○[音楽] The Who/The Real Me

タイトルはThe Whoの名盤「Quadrophenia(四重人格)」より。 

また病院に舞い戻ることになった
別の精神科医を紹介して貰いに
診察室で俺が週末に苦しんだ幻視の事を話したんだ
でもヤツはそれについて何を思ったのか漏らさず隠し通した
アンタは俺にとっての「現実」を疑ってるのか？
なあ先生よ

うちの認知症老人、 カプグラ症候群(すりかわり妄想)ときたらお次は 解離性同一性障害(多重人格)やろうなと思ってたけど、どうもすでにその状態なんやなこれ。 感情が高ぶってすりかわり妄想の症状が悪化すると、口調がすっかり変わってまるで自分がアブダクション(誘拐)されたお手伝いさんみたいな態度になるんだけど、これ別人格ですわ。

フィクションで誇張されたいわゆる多重人格ってのは、ほんとうに別の人格が存在する病気かのように広く信じ込まれてるけど、要するに

といった認知障害でごくあたりまえにみられる症状の合併症でしかないのよね、実例をまのあたりにするとああ…しょーもな…という気分になると思う。

そんで支離滅裂な妄言の中に繰り返し「先生」と呼ばれる存在がでてきて家から一歩も出てないのに「先生」と会った云々と主張するのだけど、病院の先生か学校の先生かそれともかつての趣味の先生(すでに死去)か頭捻ってたんだけど、ダニエル・キイスの著書で有名な ビリー・ミリガンがそれぞれの人格に指示を与える統合人格というべきものを「ティーチャー(教師)」と呼んでた事を思い出し、ああそれと同じなのかなぁと合点がいった。

2019/8/16(Fri)

○[オレオレN6] OpenSSL + ARM

ARMだけNローカルでasmコードにがっつりとローカルパッチ当たってるのだが、一応は元のperlスクリプトに修正して生成したとは思うんだけどそっちの修正がcommitされとらんようなのでめんどくせえ。 というかそのせいでN HEADではOpenSSL-1.1にアプデした時にregenされてローカルの変更がほとんど消し飛んでるんだけどええんかあいつら…

つーかN HEADで消えて問題ない差分ならこっちも捨てても良さそうなんだけど、念のためにNローカルパッチは何をやりたかったのかを出力されたasmコードを元に逆にperlスクリプトを修正しながら推測してみるかね…

つーことでまずはcrypto/aes/asm/aesv8-armx.plの差分 

@@ -38,6 +38,7 @@ $prefix="aes_v8";

 $code=<<___;
 #include "arm_arch.h"
+#include "arm_asm.h"

 #if __ARM_MAX_ARCH__>=7
 .text
@@ -930,13 +930,7 @@ if ($flavour =~ /64/) {                    ######## 64-bit code
        if ($arg =~ m/[qv]([0-9]+)[^,]*,\s*[qv]([0-9]+)/o) {
            my $word = $opcode{$mnemonic}|(($1&7)<<13)|(($1&8)<<19)
                                         |(($2&7)<<1) |(($2&8)<<2);
-           # since ARMv7 instructions are always encoded little-endian.
-           # correct solution is to use .inst directive, but older
-           # assemblers don't implement it:-(
-           sprintf ".byte\t0x%02x,0x%02x,0x%02x,0x%02x\t@ %s %s",
-                       $word&0xff,($word>>8)&0xff,
-                       ($word>>16)&0xff,($word>>24)&0xff,
-                       $mnemonic,$arg;
+           sprintf ".inst\t0x%08x\t@ %s %s",$word,$mnemonic,$arg;
        }
     };

@@ -980,7 +975,7 @@ if ($flavour =~ /64/) {                     ######## 64-bit code
        s/vmov\.32\s+(.*)/unvmov32($1)/geo              or
        s/^(\s+)b\./$1b/o                               or
        s/^(\s+)mov\./$1mov/o                           or
-       s/^(\s+)ret/$1bx\tlr/o;
+       s/^(\s+)ret/$1RET/o;

        print $_,"\n";
     }

まずarm_asm.hってのをN独自に用意してインクルードしてる、これの中身は 

#if defined (_ARM_ARCH_4T)
# define RET            bx              lr
#else
# define RET            mov             pc, lr
#endif

とARMv4Tとの差異を吸収するマクロが定義されてて、s/^(\s+)ret/$1bx\tlr/o; → s/^(\s+)ret/$1RET/o; の変更部分と関連している。

そんでスクリプトのコメントに「.inst命令を使うべきだけど古いasには実装されてないので.byte命令使うね」と書かれてる部分があるんだけど、Nはgasだからってことで正しく.instつかうぜという修正をいれておるもよう。

さらにこれ以外にもARM NEON IntrinsicsだかAEONでお買い物だかWAONポイントが溜まるか知らねえけどSIMD命令でなんかやってるとこで結構な差分が出るのは、OpenSSL-1.0.2kにアプデした時にasmコードを再生成しとらんので、 このcommitのCortex-A5x最適化がすっぽり抜け落ちてるんやね、うーんこの。

うーん結局のところ、Nローカルで意図して適用したパッチって実はこのARMv4T対応と.byte→.inst置換くらいで、あとはasmコード再生成忘れによるマージ漏れミスという可能性が高まってきたゾ。 やっぱりリリースエンジニアリング崩壊しとりますな…さすがは限界集落である。

しっかしこのペースでコード監査しとるとマジ終わらんな、ワイみたいにローカルパッチだけでなくOpenSSLそのもののコード監査しとるLibreSSL方面とかガチ苦行としかいいようがない。

2019/8/14(Wed)

○ 続々々・OpenSSL + MIPS

ふーんOのMIPSサポートはloongsonだけでなくsgiも32bitサポート切り捨てて完全にn64化されとるんね、ようやっとる。

Nも切り捨てないまでもo32とn64で別portの方が現実的だと思うんだが、どうもmatt案件っぽいので全てを察した。

2019/8/12(Mon)

○[オレオレN6] 続々・OpenSSL + MIPS

とりあえずgxemul -emalta でevbmips mips64el環境用意してベンチをとってみたけど、問題のAESもCコードと同等かそれ以上に性能出るようにはなった。 つーことで少なくともmips64であれば有効にしておいた方がいいという感じなんやな。

こっちがTNF N6の結果 

OpenSSL 1.0.1i 6 Aug 2014
built on: NetBSD 6.1.5
options:bn(32,32) md2(int) rc4(ptr,int) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
compiler: gcc version 4.5.3 (NetBSD nb2 20111202)
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2               8971.31        18.01k       22.09k       27.68k       27.27k
sha1                29.33k       88.24k      276.09k      320.67k      483.97k
rc4                 68.24k      728.21k      754.15k      668.54k      777.57k
des cbc             55.41k      120.56k       11.99k      114.13k       68.27k
des ede3            42.32k     9600.00        37.96k       35.33k       30.85k
aes-128 cbc        216.45k      129.56k      245.84k       24.19k      221.71k
aes-192 cbc        176.62k      176.41k      212.42k      177.80k      217.19k
aes-256 cbc        101.68k      185.50k      168.79k      187.93k      184.76k

そんでこちらがopensslconf.hの設定をLinuxと同じにしてasmコードも有効にしたオレオレN6 

OpenSSL 1.0.2k  26 Jan 2017
built on: reproducible build, date unspecified
options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
gcc version 4.5.3 (NetBSD nb2 20111202)
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2                 10.40k       21.04k       33.09k       39.72k       40.14k
sha1                45.79k      126.83k      325.21k      390.09k      568.55k
rc4                852.41k      921.17k      835.38k      827.15k      830.52k
des cbc            116.81k      101.42k      122.11k      102.74k      122.14k
des ede3            42.97k       43.51k       39.77k       37.22k       38.20k
aes-128 cbc        223.64k      242.86k      248.47k      220.41k      215.45k
aes-192 cbc        195.34k      193.07k      215.43k      213.97k      194.33k
aes-256 cbc        173.26k      155.52k      158.01k      188.16k      187.30k

うーん微妙過ぎる…

あとgxemul -emaltaはcdromエミュが機能してないっぽいので、インストールは仮想ディスクをvnd(4)経由でマウントしてtarballを展開する必要があった。 あとこっちはhpcmipsと違ってマルチユーザーで動いとるな。

○[オレオレN6] N/evbmips-mips64el

なんか変だなという疑問をエミュレーターの不具合やろで脳死してたのだが、N6/mips64ってkernelはn64だけどuserlandやkernel modueはn32でビルドされとるんやな(いちおうn64なlibも/usr/lib/64にあるのだけど)。 だからMALTA64なkernelで起動した時kernfsやらprocfsサポートが無いからエラー出るから後載せしようとmodload(8)かけるとBad system callで死ぬのか…なんやこれ… うーん全部o32/n32/n64で別portにするという選択肢無かったんすかねこれ…どん判AA略

まぁええわ、N/hpcmipsでo32の-DAES_ASMの速度がクソ遅い原因がn32で解消するなら、それはもうCPUがMIPS IIIでないからちゅーことで一件落着や、いまいち腑に落ちんが。

それにしても/usr/testsもn32なバイナリなのでn64なlibcryptoの動作確認のしようが無くて困るのだがどうすっかねこれ…