# xv6の構成要素の継続の分析

# 研究目的

OS自体そのものは高い信頼性が求められるが、 OSを構成するすべての処理をテストするのは困難である。
テストを利用する以外の手法で信頼性を高めたい。
OSの状態を状態遷移を基本としたモデルに変換し形式手法を用いて信頼性を高める手法を検討する
小さなunixであるxv6 kernelを、状態遷移を基本とした単位でのプログラミングに適したCbCで再実装を行っている
このためには現状のxv6kernelの処理の状態遷移の分析が必要である。
- その結果を、継続ベースでのプログラミングに変換していく必要がある。
xv6kernelの構成要素の一部に着目し、状態遷移系の分析と状態遷移系を元に継続ベースでxv6の再実装を行う。

# やったこと

zoom黙々配信的なもの
- LLVMは敗れ去りました…
OS研究会の申し込み
システム管周りの細々したタスク
自宅のインターネット強化
寄稿するPerlの記事を書く作業

# LLVM

ヘッダーファイルに変更を加えた場合はninja-build cleanではだめで、潔くrm -rfしないとだめらしい
grepしてLevelに関係がありそうなものにTailCallEliminationを追加する方針でやったがあまり意味がない
やはりpass一覧を出してやるしかなさそう

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


--- a/clang/lib/CodeGen/BackendUtil.cpp Tue Apr 14 15:43:20 2020 +0900
+++ b/clang/lib/CodeGen/BackendUtil.cpp Tue Apr 21 16:59:10 2020 +0900
@@ -315,6 +315,10 @@
     PM.add(createGVNPass());
     PM.add(createInstructionCombiningPass());
     PM.add(createDeadStoreEliminationPass());
+#ifndef noCbC
+  } else {
+     PM.add(createTailCallEliminationPass(true));
+#endif
   }
 }

CGCallのところは後ほど実装するという感じでコメントにしていたので、しっかり実装した
とは言え現在の最適化しないとエラーが出る処理とはあんまり関係性が無かった

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


diff -r 980e56f2e095 clang/lib/CodeGen/CGCall.cpp
--- a/clang/lib/CodeGen/CGCall.cpp      Tue Apr 14 15:43:20 2020 +0900
+++ b/clang/lib/CodeGen/CGCall.cpp      Tue Apr 21 16:59:10 2020 +0900
@@ -4440,6 +4440,33 @@
     terminates local variable pointer life time here.
     cf. CodeGenFunction::PopCleanupBlock at clang/lib/CodeGen/CGCleanup.cpp
 */
+
+  if (this->FnRetTy.getTypePtr()->is__CodeType() && CallInfo.getReturnType().getTypePtr()->is__CodeType() && ! EHStack.empty() ) {
+  EHCleanupScope &Scope = cast<EHCleanupScope>(*EHStack.begin());
+  auto *CleanupSource = reinterpret_cast<char *>(Scope.getCleanupBuffer());
+  alignas(EHScopeStack::ScopeStackAlignment) char
+      CleanupBufferStack[8 * sizeof(void *)];
+  std::unique_ptr<char[]> CleanupBufferHeap;
+  size_t CleanupSize = Scope.getCleanupSize();
+  EHScopeStack::Cleanup *Fn;
+
+  if (CleanupSize <= sizeof(CleanupBufferStack)) {
+    memcpy(CleanupBufferStack, CleanupSource, CleanupSize);
+    Fn = reinterpret_cast<EHScopeStack::Cleanup *>(CleanupBufferStack);
+  } else {
+    CleanupBufferHeap.reset(new char[CleanupSize]);
+    memcpy(CleanupBufferHeap.get(), CleanupSource, CleanupSize);
+    Fn = reinterpret_cast<EHScopeStack::Cleanup *>(CleanupBufferHeap.get());
+  }
+
+  EHScopeStack::Cleanup::Flags cleanupFlags;
+  if (Scope.isNormalCleanup())
+    cleanupFlags.setIsNormalCleanupKind();
+  if (Scope.isEHCleanup())
+    cleanupFlags.setIsEHCleanupKind();
+  Fn->Emit(*this, cleanupFlags);
+  }
+
 #endif

# OS研究会

「xv6の構成要素の継続の分析」で出しました
内容としては優さんの修論と坂本くんの卒論をmixした内容
- 修論/卒論では具体的な分析までは行ってなかったので、行う必要がある
卒論/修論ではInterface周りの話が中心でしたが、今回はあまり触れない
- どちらかというとInterfaceに分割した処理の内容の方をフォーカスしていこうと思います

# 修論/卒論時点での書き換え方針

もともとあった関数内で、basic block単位でCodeGearに変換していく
かなり愚直に変換した為、 CodeGearの引数にループindexが含まれてたりしていた
- 特別Gears用のAPIがある訳ではない
- 現状はInterface化したが、実装は1つしか存在していない
この時点では具体的に各CodeGearの意味までは考えられてなかった
- 今回の論文はこのあたりが主軸になりそう

# やること

メモリ関連(vm.c)とファイルシステム関連(fs.c)の読み直し
修論/卒論でのCbCの実装を確認しつつ、状態遷移図がしっかり説明できる単位で状態を切り分けていく
CbCとxv6なのでB4と一緒にやるのもいいかもねみたいな気がする ( or 院の講義でやってしまう)
…というのを論文を書きながら進めていく

# シス管周りのほそぼそ系

消しちゃったVM復旧させたりとか…
B2とzoomでつなぎながら作業
- アカウントの作成とか
mattermostサーバーのメンテンス
- スペック強化、 ntp(chrony)クライアントの追加とうとう
- 実際に作業してもらったのは宮平くん

2020/04/21

2020/04/21

# xv6の構成要素の継続の分析

# 研究目的

# やったこと

# LLVM

# OS研究会

# 修論/卒論時点での書き換え方針

# やること

# シス管周りのほそぼそ系