#久々に動かした NetBSD/gigalandisk (arm) では gauche 動かなくなってることが判明。
#どうやら duoble でも 8byte align されないみたい。
#他の arm ではどうなんでしょ？
#gigalandisk(ARM9?)にNetBSDとは面白そうですね。コンパイラオプションとかはどうでしょう ("ADS1.2 ビルド848"の場合は不具合があったようです) > どうやら duoble でも 8byte align されないみたい
#最新コミットで、gccの__attribute__使ってアラインさせるようにしてみたんだけどどうでしょう。
#実はもうひとつ、プリコンパイルで生成されるScmWordのアレイの方でも、PairやVectorを作ってる場合は8byte alignになるようにしなくちゃならないということに気づいて修正中。
#ありがとうございます。doubleの場合は不正でなくてもその方が(性能が)よいですね。今朝方、0.9(.exe)も載せさせていただきました。明日は会社だな… > 最新コミットで、gccの__attribute__使ってアラインさせるようにしてみた…
#いま co して configure 中
…
#あ、こっちは 0.9 のあとの trunk だから 0.9 まずつくらなきゃ。
#もしくは既に0.9が入ってるマシンでcoしてDIST tgzするとか。
#make 中だけど、先回りして module.o だけ作ってみました。
## nm module.o | grep ' b '
00000050 b gaucheModule
00000078 b gfModule
000000c8 b internalModule
000000f0 b modules
00000000 b nullModule
00000028 b schemeModule
000000a0 b userModule
#大丈夫そうかな。
#staticなやつがやばいんですよ。ScmStringの配列とか、ScmSlotAccessorとか。
#以前は少なくともこれらも 4 とか c になってたので。
#あれれ。ScmObjそのものは単なるポインタなので4byte境界でもいいんだけどな
#ま、とりあえず mkae の進行をみてましょう。
#あれ、でも下 3 bit つかってません？
#というか32bit machineでScmObjが8byte alignされちゃうと、precompが吐くワード配列に余分なパディングは入っちゃうから動かない可能性大。
#下3bitが問題になるのは、ScmObjが指す先の実体です。
#じゃあ何か勘違いしてたのかな
#gauche-develでレポートがあったケースはScmSlotAccessorの実体が8byte alignされないってやつで、
#見直してたらScmStringもその可能性があるなとか気づいたという。
#でも妙だな。precompの吐く配列でScmPairやScmVectorが8byte alignされないケースは確かに出てくるんだけど、今までなんで問題にならなかったんだろう。
#手元では ScmClassRec と ScmModule に attribute(aligned) 追加したら動いたように見えたのは、その後がそろったからとか、そういう偶然だったのかな。
#ああそうか、ScmModuleもstaticにとられてましたね。だからnullModuleとかが8byte alignになってるのはそれはそれで良いことなのだな。(さっきはこいつらがScmModule* だと勘違いしてた)
#ようやく compile.c ...
#../../src/gosh -ftest ../../src/precomp -e -P -o gauche--collection ../../libsrc/gauche/collection.scm
*** Signal 11
Stop.
#でした
#むむむむ。プリコンパイルアレイの方もやらんとだめかいな。今コードいじってるんでちょいまち。
#あれ、待てよ。ScmPairは4byte境界でもいいのか。
#ああ、doubleは8byteじゃないとタグ判定を誤るな。ScmFlonumにもSCM_OBJ_ALIGNつけてください。
#思い出してきたぞ。8byte alignでないとだめなのは、ScmFlonumと、memory allocated objectの先頭から指される可能性のあるオブジェクト=ScmClassだけだ。他のmemory allocated objectは4byte alignで構わない。
#はず。ってことはgauche-develのassertion failureが謎だなあ。ScmClassRecの先頭に仕込んであったdoubleによる強制アラインが効かなかったってことなのかなあ。
#Index: src/gauche.h
===================================================================
--- src/gauche.h (revision 6884)
+++ src/gauche.h (working copy)
@@ -298,7 +298,7 @@
typedef struct ScmFlonumRec {
double val;
-} ScmFlonum;
+} ScmFlonum SCM_OBJ_ALIGN;
#define SCM_FLONUM(obj) ((ScmFlonum*)(SCM_WORD(obj)&~0x07))
#define SCM_FLONUMP(obj) (SCM_TAG2(obj) == 2)#そうそう。
#コンパイル始めました。また３０分くらいかな
#30分もかかりますか。普段1分半でコンパイルしちゃってるから感覚がずれるな。
#こんどは gc をcompileしないからそうまでかからないかな。でも 400Mhz ですからねえ。いま number.c です。
#同じ結果でした。
#doh.
#gosh -ftest はこう落ちます。
#(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x200aaaf0 in write_walk (obj=0x0, port=0xd4c30, ctx=0xbfffe240) at write.c:371
371 if (!SCM_PTRP(obj) || SCM_KEYWORDP(obj) || SCM_NUMBERP(obj)
(gdb) bt
#0 0x200aaaf0 in write_walk (obj=0x0, port=0xd4c30, ctx=0xbfffe240)
at write.c:371
#1 0x200aab7c in write_walk (obj=0x115dc8, port=0xd4c30, ctx=0xbfffe240)
at write.c:379
#2 0x200aae10 in write_ss (obj=0x115dc8, port=0xd4d20, ctx=0xbfffe240)
at write.c:567
#3 0x200acb20 in Scm_Vprintf (out=0xd4d20, fmt=<value optimized out>,
ap=<value optimized out>, sharedp=1) at write.c:1136
#4 0x200acf18 in Scm_Vsprintf (
fmt=0x20149220 "no applicable method for %S with arguments %S",
ap=0xbfffe3e4, sharedp=1) at write.c:1324
#5 0x2008e710 in Scm_Error (msg=0x20175a43 "") at error.c:542
#6 0x20090120 in Scm_NoNextMethod (argv=<value optimized out>,
argc=<value optimized out>, gf=0x20175dc8) at class.c:1993
#7 0x20075ef0 in run_loop () at ./vmcall.c:341
#8 0x20087d14 in user_eval_inner (program=<value optimized out>,
codevec=0xbfffe798) at vm.c:1297
#9 0x20088720 in apply_rec (vm=<value optimized out>,
proc=<value optimized out>, nargs=<value optimized out>) at vm.c:1383
#10 0x20072120 in Scm_Init (signature=0xb634 "0.9,utf8,pthreads") at core.c:165
#11 0x0000a260 in main (argc=2, argv=0xbfffe954) at main.c:332
(gdb)#それはgauche-develでレポートされたのと似てるな。とりあえず一回何かでエラーになって、そのエラーを表示しようとしてるところで落ちてると。
#alignment以外の問題っぽいなあ。これ以上は実機がないときついか…
#(gdb) p nullModule
$1 = {hdr = {tag = 0x2017915b ""}, name = 0x20178820, imported = 0x20b,
exported = 0x20b, exportAll = 0, parents = 0x20b, mpl = 0xd8fe8,
depended = 0x20b, table = 0xd9f78}
(gdb)#肝心のclass が align されていない？
#@@ -423,7 +423,7 @@
typedef struct ScmInstanceRec {
ScmByte *tag; /* private */
ScmObj *slots; /* private */
-} ScmInstance;
+} ScmInstance SCM_OBJ_ALIGN;
#define SCM_INSTANCE_HEADER ScmInstance hdr /* for declaration */#これでとりあえずさっきまで落ちていたところは通過しました。
#../../src/gosh -ftest guess.scm guess_tab.c
*** Signal 11
Stop.
#ここまではきた。
#Program received signal SIGSEGV, Segmentation fault.
0x30303030 in ?? ()
(gdb) bt
#0 0x30303030 in ?? ()
#1 0x0019cca8 in ?? ()
Cannot access memory at address 0x30303030
(gdb) info regi
r0 0x19cca8 1690792
r1 0x19cc90 1690768
r2 0x4 4
r3 0x0 0
r4 0x30303030 808464432
r5 0x30303030 808464432
r6 0x30303030 808464432
r7 0x30303030 808464432
r8 0x30303030 808464432
r9 0x0 0
r10 0x30303030 808464432
r11 0x30303030 808464432
r12 0x201b70f0 538669296
sp 0x30303030 808464432
lr 0x19cca8 1690792
pc 0x30303030 808464432
fps 0x0 0
cpsr 0x60000010 1610612752
(gdb)
#ああそうか。SCM_INSTANCE_HEADERはSCM_HEADERを直接含んでなかったんだっけ。
#今のsvn trunkではScmClass自体にSCM_ALIGN8をつけるようになってます (マクロ名変えました)
#そのレジスタの値は何だろう、スタックを書き潰した?
#score-f で落ちるみたい。
#gosh> (load "./guess.scm")
#t
gosh> (define d (all-dfas))
d
gosh> (define arcs (append-map arcs-of (states-of (car d))))
arcs
gosh> (define arc (car arcs))
arc
gosh> (score-of arc)
Program received signal SIGSEGV, Segmentation fault.
0x30303030 in ?? ()
(gdb) bt
#0 0x30303030 in ?? ()
#1 0x0024ef30 in ?? ()
Cannot access memory at address 0x30303030
(gdb)
#む、そこで落ちるということはdoubleのアライン問題くさい? なぜスタックを潰しているかは謎だが。
#(ref arc 'score) だと値を読めます?
#gosh> (ref arc 'score)
Program received signal SIGSEGV, Segmentation fault.
0x30303030 in ?? ()
(gdb)
#おなじですね
#念のため、(define f (ref arc 'score)) だと大丈夫? そんでもって (class-of (ref arc'score))) だと落ちる?
#gosh> (define f (ref arc 'score))
f
gosh> (class-of (ref arc 'score))
#<class <real>>
gosh>
#どっちも落ちないですね。
#あ、class-ofはいけるのか。
#(define f (list (ref arc 'score))) では?
#gosh> (define f (list (ref arc 'score)))
f
gosh>
#です
#ふーむ、ということは表示しようとして落ちるのかな。(decode-float (ref arc 'score))すると?
#gosh> (decode-float (ref arc 'score))
#(1072693248 -1074 1)
gosh>
#それは最小限に近いところだな。denormalized領域の表示部に何かあるかな
#試しに 5e-315を評価すると?
#gosh> 5e-315
#帰ってきませんね
#やっぱり表示部くさいな。
#gosh> 5e-315
^C
Program received signal SIGINT, Interrupt.
0x200cbe0c in bignum_mul_word (br=0x17aa18, bx=0x2fa948,
y=<value optimized out>, off=3123528) at bignum.c:844
844 for (i=0; i<bx->size; i++) {#んー待てよ。(decode-flonum 3.14)とやるとどうなりますか?
#decode-flaot ですか？
#あ、そうです。
#gosh> (decode-float 3.14)
#(7746193636007608 235 1)
gosh>
#float
#でした
#あ、多分わかった。doubleのエンディアンじゃないかな。
#あー、arm って変だったっけ
#gauche/config.hのDOUBLE_ARMENDIANが定義されてますか? 定義されてたら、#undefして試してみてください。定義されてなかったら、定義して試してみてください。
#armはプロセッサの設定で切り替えられたと思うんだけど、今Gaucheはアーキテクチャにarmって入ってるとDOUBLE_ARMENDIANを定義しちゃうんで、(1)プロセッサがmixed endianじゃない設定になってるか、(2)プロセッサはmixed endianなんだけどアーキテクチャでarmを広い損ねてるか、どっちかかなと。
#define されていたので undef して make してます
#じゃあケース(1)ですかね。いよいよcofnfigure時にテストプログラムを走らせるしかないかなあ。
#でもこの辺って、0.8.14 -> 0.9 で変わりました？
#表示部まわりはいじってない… flonum自体の表現は変わったけど。
#0.8.14 は少なくとも正常に build はできるんですよ、同じマシンで。
#それは謎だなあ。
#あ、まてよ。2009-08-21のMAX_EXPONENTの変更はここに影響を与えてるな。もしかするとそれで隠れてた問題が表面化したのかも。
#あれでも undef にしたら guess_tab.c はできますね
#0.8.14 でできたというのは、さっきの alignment でおちたところまでしか確認してなかったかもしれない。
#x86とバイナリ表現同じだから undef が正解なのか
#さっきのguessで落ちる件のみについて言えば、endianの問題でscore-ofが非常に小さな値になってたわけだけど、あれは0.8.14だと0.0と出力されてたかもしれない。それで問題無く通過してたのかも。
#sxml までいきました。
#../../src/gosh -ftest ./trans.scm ./sxml-sxpath.scm.in
../../src/gosh -ftest -I. -ladaptor -E "import sxml.adaptor" ../../src/precomp -e -i sxpath.sci -o sxml--sxpath sxml-sxpath.scm
Error in compiling (use sxml.adaptor)
Error in compiling (define-module sxml.sxpath (use srfi-1) (use srfi-2) (use srfi-11) (use srfi-13) (use text.parse) (use sxml.adaptor) (export sxpath nodeset? as-nodeset sxml:element? ntype-names?? ntype?? ntype-namespace-id?? sxml:invert node-eq? node-equal? node-pos sxml:filter take-until take-after map-union node-reverse node-trace select-kids node-self node-join node-reduce node-or node-closure if-sxpath if-car-sxpath car-sxpath sxml:id-alist sxml:string sxml:boolean sxml:number sxml:string-value sxml:node? sxml:attr-list sxml:id sxml:equality-cmp sxml:equal? sxml:not-equal? sxml:relational-cmp sxml:attribute sxml:child sxml:parent sxml:ancestor sxml:ancestor-or-self sxml:descendant sxml:descendant-or-self sxml:following sxml:following-sibling sxml:namespace sxml:preceding sxml:preceding-sibling sxml:child-nodes sxml:child-elements))
*** ERROR: Compile Error: cannot find file "sxml/adaptor" in *load-path* ("." "../../lib" "../../libsrc" "../../src" "/usr/local/share/gauche/site/lib" "/usr/local/share/gauche/0.9/lib")
Stack Trace:
_______________________________________
0 (eval `(use ,mod) (compile-module))
[unknown location]
1 fn
2 (port-fold compile-toplevel-form '() read)
At line 204 of "../../lib/gauche/cgen/precomp.scm"
3 (with-input-from-file src (cut emit-toplevel-executor (reverse (po ...
At line 202 of "../../lib/gauche/cgen/precomp.scm"
4 (match:error args)
[unknown location]
*** Error code 70
Stop.#あーしまった。それは多分provideを取り除いた影響だ。
#そんなところで影響が出てたとは。
#んー、とりあえず、MakefileのSCMCOMPILEのコマンドラインの-E "import sxml.adaptor"の後に-E "provide \"sxml/adaptor\"" をつけてみたらどうかな。
#-E 'provide "sxml/adaptor"' の方がいいかな。
#今前者で make してます
#手元では既にインストールされてたsxml.adaptorをロードしてたんで気づかなかったんだな。
#うまくいってるようです
#最後まで言ったのでmake test中
#Total: 9988 tests, 9988 passed, 0 failed, 0 aborted.
#でした
#やた。
#gauche-develに報告が上がってるやつは二つとも落ちてる箇所が違うんだけど、とりあえずalignmentとDOUBLE_ARMENDIANを試してもらおう。
#ありがとうございます >enami
#こちらこそありがとうございます。これで pkgsrc にパッチいれられます。
#DOUBLE_ARMENDIANのチェックだけど、configure時にやるのはクロスコンパイルのことを考えると少々厄介だな。実行時にやっちゃおうかな。
#そうすると native でない浮動小数点 binary も読みやすくなる？
#pkgsrc でもうまくいった
#Total: 10025 tests, 10024 passed, 1 failed, 0 aborted.
#1 failed は pkgsrc でbuild すると $HOME が workdir にセットされるため。
Gauche > Archives > 2009/11/29