FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/

Vivado Simulatorで波形デバッグする環境を構築する

僕は波形デバッグはあまり好きではなく、基本的に波形を水にログファイルだけでデバッグできるようにしておきたいのだが、ベーシックな部分を観測するためには最後には波形デバッグが必要だ。 そこで、Vivado Simulatorを使った時の波形デバッグの環境を構築しよう。やりたいことは、GUI付きでのシミュレーション、波形の追加などの操作だ。

波形ダンプ付きのコンパイル

Vivado Simulatorにおいて、GUI付きでデバッグをするためには、xsimにおいて-guiを追加すると良い。

xsim run_tb_mag_top -gui

ただしこれだけでは波形のダンプは取得できず、コンパイル時にデバッグオプションを追加しておかないと怒られる。

xelab -debug wave -s run_tb_mag_top work.tb_mag_top --timescale 1ns/100ps

Vivado Simulator実行時のさまざまなコマンド

自分がはまったのは、-R と -onfinishの考え方だ。

-R : シミュレーションを最後まで実行し、終了します (「run -all; exit」を実行)。

これを最初つけていたのだが、これを付けたままGUIを起動すると、シミュレーションが終了するとすぐにウィンドウも閉じられてしまう。これではデバッグできない。 結論としては、-Rオプションを除くだけでよい。ついでに、シミュレーション終了時の挙動を変えるためには、onfinishオプションも使用できる。

-onfinish stop|quit : シミュレーションが終了したときの動作を指定します。有効な値はquit および stop で、デフォルトは stop です。

基本的にstopのままで良いと思われるが、-Rを使わずにウィンドウも閉じたいときは、-onfinish quitを指定しておけばよいのかな。

Vivado SimulatorでのFPGA Primitiveモジュールの指定方法

Vivado Simulatorにおいて、XilinxのIPを使ってシミュレーションをしようとしたところ、Primitiveなモジュールが存在しないと怒られてしまった。

ERROR: [VRFC 10-2063] Module <GND> not found while processing module instance <GND> [... funcsim.v:2047]
  GND GND
       (.G(\<const0> ));

そういえば、Vivado Simulatorにおいてfsblのようなモジュール群を読み込むためにはどうしたらよいのかと思い調査したところ、ちゃんとVivadoにもunisimのようなライブラリ群が存在していた。

っていうか、以下のFAQを見る限り、これらのライブラリは別に指定しなくても読み込まれるという理解だったんだけどな。

AR# 64052 - Vivado シミュレーション ライブラリの使用 - UNISIM ライブラリ

Vivado 2015.4ならば、以下のVerilogファイルがそれに相当するようだ。

c:/Xilinx/Vivado/2015.4/data/verilog/src/unisim_comp.v

とりあえずfilelistにこのファイルを追加すると、無事にコンパイルされるようになった。

それともう一つ、このunisim_comp.vにはタイムスケールの指定が無いため、コンパイルに失敗するケースがある。

ERROR: [XSIM 43-4099] "c:/Xilinx/Vivado/2015.4/data/verilog/src/unisim_comp.v" Line 3236. Module GND doesn't have a timescale but at least one module in design has a timescale.

これもオプションを調査して行くと、xelabの実行時にタイムスケールを指定すれば良さそうだ。

  COMMAND xelab -s run_tb_mag_top work.tb_mag_top --timescale 1ns/100ps

これで、コンパイルとシミュレーションが無事に通るようになった。

Vivado Simulatorを使ってシミュレーションを行う環境を立ち上げる(Mingwで挑戦)

以前、CMakeを使ってVerilogシミュレーションの環境を整える準備を行った。趣味でVerilogを書いている中で、Windows上のVivadoでシミュレーションを行う必要が出てきたため、環境を構築しよう。

msyksphinz.hatenablog.com

利用したのは、Cygwinから若干進化して、MingW64上で構築を行っている。

MingW上での必要なパッケージのインストール

Verilogの自動生成のための環境として、rubyと、cmakeのインストールを行った。 これはパッケージインストールをするだけで完了できる。

pacman -S ruby cmake

Vivadoの環境の構築

MingWの環境では、vivado_settingsもちゃんと動作した。

/c/Xilinx/Vivado/2015.4/settings64.sh

あとは、CMakeで必要なVerilogファイルを記述するだけだ。ファイルリストは、以下のようにしたものを利用している。

HW_DIR/mag_core/mag_top/sim/tb_mag_top.v
#include "../rtl/mag_top.f"

シミュレーションベンチと、RTLファイルリストを分けて記述している。 あとは、以前の記事でテンプレートを作成したCMakeLists.txtを移植して、cmakeの実行と、シミュレーションを実行するだけだ。

ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:85]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:93]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:101]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:109]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:117]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:125]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:133]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:141]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:149]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:157]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:165]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:173]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:181]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:189]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:205]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:565]
ERROR: [VRFC 10-1412] syntax error near , [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:573]
ERROR: [VRFC 10-91] IF_INST is not declared [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:53]
ERROR: [VRFC 10-91] IF_INST is not declared [C:/msys64/home/masayuki/work/magnetor-1/hardware/mag_core/mag_idu/rtl/riscv_ctrl.v:61]

いろいろと怒られてしまった。あとで修正しよう。

RedPenを使って自分の文章を校正してみる

僕はどちらかというとドキュメントを書くのが好きだ。ドキュメントって、正直言うと何も考えずに書くことができる。普段プログラムを書いたり回路を設計しているときは、頭を回転させないとちゃんとしたものが作れない。しかし、仕様書とかドキュメントって、その実何も考えずに作ることができるのだ。そういう意味で、僕はドキュメント作成はエンジニアにとって急速の時というか、いったん休憩を挟むのにちょうど良いものだと考えている。

ただしそんな気持ちでドキュメント作成に臨んでいるもんだから、クオリティが高いとは言えない。実際、自分で読み直してみると何書いてんだかわかんない時がある。 大学の卒業論文では、第1項を六に自分でチェックせずに先輩に見せたものだから、ずいぶんと訂正させられたものだ。 まあ、文章のストーリー性や組み立て方はともかく、一文一文を読みやすいものにしておきたい。そこで、文章校正ツールとしてRedPenを使ってみよう。

dev.classmethod.jp

RedPen の特徴 設定が柔軟に行えます。(カスタマイズも柔軟) どのような言語で書かれた文書でも処理できます。(もちろん日本語も OK です) Markdown や Textile フォーマットで記述された文書をそのまま検査できます。

良さそうね。

RedPenのダウンロードとインストール

対象は、Ubuntu15.10だ。インストールにはJava 8とMavenが必要らしい。

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install oracle-java8-installer

次にRedPenをダウンロードする。

wget https://github.com/redpen-cc/redpen/releases/download/redpen-1.5.3/redpen-1.5.3.tar.gz
tar xvfz redpen-1.5.3.tar.gz
cd redpen-distribution-1.5.3/
./bin/redpen -c conf/redpen-conf-ja.xml sample-doc/ja/sampledoc-ja.md
...
[2016-03-27 14:46:00.463][ERROR] cc.redpen.Main - The number of errors "28" is larger than specified (limit is "1").

いくつかエラーが表示された。なるほど、こうやって校正していくのね。 じゃあ、僕の作ったドキュメントを使うとどうなるんだろう。

自分の翻訳資料をRedPenで構成してみる

xv6のドキュメントを、日本語化したものを公開している。これを使って、校正をかけてみよう。

github.com

git clone https://github.com/msyksphinz/xv6_translate.git
./redpen-distribution-1.5.3/bin/redpen -c ./redpen-distribution-1.5.3/conf/redpen-conf-ja.xml xv6_translate/chapter0.md
...
とを見ることができるだろう。
chapter0.md:283: ValidationError[DoubledWord], Found repeated word "に". at line: xv6を学んだあとは、読者はより複雑なオペレーティングシステムを学ぶことによって、xv6の内部の考え方がそれらのシステムにも同様に存在しているこ
とを見ることができるだろう。
chapter0.md:283: ValidationError[DoubledWord], Found repeated word "こと". at line: xv6を学んだあとは、読者はより複雑なオペレーティングシステムを学ぶことによって、xv6の内部の考え方がそれらのシステムにも同様に存在している
ことを見ることができるだろう。
chapter0.md:283: ValidationError[DoubledWord], Found repeated word "を". at line: xv6を学んだあとは、読者はより複雑なオペレーティングシステムを学ぶことによって、xv6の内部の考え方がそれらのシステムにも同様に存在しているこ
とを見ることができるだろう。
chapter0.md:283: ValidationError[DoubledWord], Found repeated word "こと". at line: xv6を学んだあとは、読者はより複雑なオペレーティングシステムを学ぶことによって、xv6の内部の考え方がそれらのシステムにも同様に存在している
ことを見ることができるだろう。
chapter0.md:283: ValidationError[DoubledWord], Found repeated word "が". at line: xv6を学んだあとは、読者はより複雑なオペレーティングシステムを学ぶことによって、xv6の内部の考え方がそれらのシステムにも同様に存在しているこ
とを見ることができるだろう。
chapter0.md:283: ValidationError[SpaceBetweenAlphabeticalWord], Space not present before an alphabetical word. at line: 本書はxv6をUnix系のインタフェースインタフェーウとして実装する方法について述べるが、アイデアと概念はUnixだけに適用されるものではない。
chapter0.md:283: ValidationError[SpaceBetweenAlphabeticalWord], Space not present before an alphabetical word. at line: 本書はxv6をUnix系のインタフェースインタフェーウとして実装する方法について述べるが、アイデアと概念はUnixだけに適用されるものではない。
chapter0.md:283: ValidationError[SpaceBetweenAlphabeticalWord], Space not present after an alphabetical word. at line: 本書はxv6をUnix系のインタフェースインタフェーウとして実装する方法について述べるが、アイデアと概念はUnixだけに適用されるものではない。
chapter0.md:283: ValidationError[SpaceBetweenAlphabeticalWord], Space not present before an alphabetical word. at line: 本書はxv6をUnix系のインタフェースインタフェーウとして実装する方法について述べるが、アイデアと概念はUnixだけに適用されるものではない。
chapter0.md:283: ValidationError[SpaceBetweenAlphabeticalWord], Space not present after an alphabetical word. at line: 本書はxv6をUnix系のインタフェースインタフェーウとして実装する方法について述べるが、アイデアと概念はUnixだけに適用されるものではない。

[2016-03-27 14:49:44.465][ERROR] cc.redpen.Main - The number of errors "1663" is larger than specified (limit is "1").

めちゃ怒られた。これはひどい

分類してみる

SectionLength : The number of characters in the section (2,141) exceeds the maximum of 1,500.

セクションの長さの規定か。これ以上長く書くなということ?まあ確かに、一節が長いと読む気はなくなるかもしれない。ってか、これを出すってことはMarkdownのセクションをちゃんと認識してるってことね。えらい。

ValidationError[DoubledWord], Found repeated word

これ、結構多い。どうやら、接続詞などを続けても怒られるようだ。確かに、僕は接続詞と句読点で文章を続ける傾向があるので、それは大量に指摘されるのかもしれない。

ValidationError[SpaceBetweenAlphabeticalWord], Space not present before an alphabetical word.

そうなんだ。細かいね...

どうやら、上記の3種類がよく怒られるエラーの代表らしい

ここら辺は、キチンと気を付けて書ける人はどれくらいいるんだろうか。。。

というわけでこのエントリを校正してみる

./redpen-distribution-1.5.3/bin/redpen -c ./redpen-distribution-1.5.3/conf/redpen-conf-ja.xml ./diary.md
...
[2016-03-27 14:57:08.330][ERROR] cc.redpen.Main - The number of errors "72" is larger than specified (limit is "1").

あらまあ。でも、

diary.md:1: ValidationError[DoubledWord], Found repeated word "と". at line: 僕はどちらかというとドキュメントを書くのが好きだ。

これは勘弁してほしいかなあ。

GCCのインラインアセンブラの構文について調査

xv6には、以下のような記述がある。

github.com

static inline void
insl(int port, void *addr, int cnt)
{
  asm volatile("cld; rep insl" :
               "=D" (addr), "=c" (cnt) :
               "d" (port), "0" (addr), "1" (cnt) :
               "memory", "cc");
}

インラインアセンブラだが、構文がいまいち意味が分からない。どういう意味だろう?

GCCインラインアセンブラについて

asm文を使うことで、インラインアセンブラを利用できる。さらに、volatileを付加することで、最適化による命令削除を抑止することができるのだが、それ以外の文法はどういう意味だ? 調査してみると、これは拡張アセンブリ構文というものであるらしい。以下のサイトが参考になった。

GCC Inline Assembler

__asm__ ( アセンブリテンプレート
        : 出力オペランド                    /* オプション */
        : 入力オペランド                    /* オプション */
        : 破壊されるレジスタのリスト        /* オプション */
);      

出力オペランド、入力オペランドを指定することで、インラインアセンブラC言語の変数を交互にやり取りさせることができる。さらに、破壊レジスタを指定することで、インラインアセンブラ内で破壊されるレジスタを指定し、コンパイラにあらかじめレジスタの退避を指定することができる。

簡単な例

ここで、理解を深めるために簡単な例を作ってみた。

int inline_test (int a, int b)
{
  int ret;
  asm volatile ("addw %0, %1, %2"
                : "=r"(ret)
                : "r"(a), "r"(b)
                :
                );
  return ret;
}

int inline_test2 (int a, int b)
{
  return a + b;
}

inline_testでは、インラインアセンブリを利用している。オペランドはすべて拡張インラインアセンブラで指定されている。それぞれ、0番目、1番目、2番目のオペランドとして記述されているのだが、どうやら拡張構文におけるオペランドリストの順に番号が付くらしい。ここでは、

  • %0 : ret
  • %1 : a
  • %2 : b

と対応がつけられた。コンパイルしてみよう。

$ riscv64-unknown-elf-gcc -O3 -c inline.c
$ riscv64-unknown-elf-objdump -D inline.o

inline.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <inline_test>:
   0:   00b5053b                addw    a0,a0,a1
   4:   00008067                ret

0000000000000008 <inline_test2>:
   8:   00b5053b                addw    a0,a0,a1
   c:   00008067                ret

ちゃんと対応が取られているね。

xv6における拡張インラインアセンブラの利用

では、改めてxv6のx86.hを見てみよう。以下のようなインラインアセンブリの記述がある。

static inline void
insl(int port, void *addr, int cnt)
{
  asm volatile("cld; rep insl" :
               "=D" (addr), "=c" (cnt) :
               "d" (port), "0" (addr), "1" (cnt) :
               "memory", "cc");
}

不思議なのは、ここでアセンブラとしてはオペランドの指定が一つもないことだ。 そもそも、rep inslという命令は、ECXで指定されたカウンタだけinslを繰り返すというものになる。破壊されるのは、メモリとccだ。あれ、ccって何だ? とりあえず、ここでコンパイルされたコードを見てみよう。

static inline void
insl(int port, void *addr, int cnt)
{
80102548:       55                      push   %ebp
80102549:       89 e5                   mov    %esp,%ebp
8010254b:       57                      push   %edi
8010254c:       53                      push   %ebx
  asm volatile("cld; rep insl" :
8010254d:       8b 55 08                mov    0x8(%ebp),%edx
80102550:       8b 4d 0c                mov    0xc(%ebp),%ecx
80102553:       8b 45 10                mov    0x10(%ebp),%eax
80102556:       89 cb                   mov    %ecx,%ebx
80102558:       89 df                   mov    %ebx,%edi
8010255a:       89 c1                   mov    %eax,%ecx
8010255c:       fc                      cld
8010255d:       f3 6d                   rep insl (%dx),%es:(%edi)
8010255f:       89 c8                   mov    %ecx,%eax
80102561:       89 fb                   mov    %edi,%ebx
80102563:       89 5d 0c                mov    %ebx,0xc(%ebp)
80102566:       89 45 10                mov    %eax,0x10(%ebp)
               "=D" (addr), "=c" (cnt) :
               "d" (port), "0" (addr), "1" (cnt) :
               "memory", "cc");
}
80102569:       5b                      pop    %ebx
8010256a:       5f                      pop    %edi
8010256b:       5d                      pop    %ebp
8010256c:       c3                      ret

cldが実行される前に、レジスタの退避をしている。それぞれ、オペランド制約で指定されたレジスタの退避と、もとに戻す作業が入っている。

xv6を移植するときに書き換えるルーチンについて調査(1)

xv6はx86をベースに書かれている。当然、プリミティブな部分はx86の命令を使って記述されているのだが、その部分をしっかり理解すれば、他のOSへの移植も簡単に行うことができるのではないだろうか。 今回は、xv6をRISC-Vに移植することを前提に、xv6のどの部分を書き換える必要があるのか調査した。

xv6のプリミティブが格納されているファイル群

まずは調査する必要があるのが、x86.hだ。

github.com

ここには、いくつか移植の必要な関数群が存在する。一つ一つ調査していく。

inb(ushort port)

inbは、デバイスアクセス用の関数、x86では独自にデバイスアクセス用の命令が用意されており、それがin命令ということになる。このあたりのx86の動作については、下記の書籍にも言及があり、参考になる。

自作エミュレータで学ぶx86アーキテクチャ-コンピュータが動く仕組みを徹底理解!

自作エミュレータで学ぶx86アーキテクチャ-コンピュータが動く仕組みを徹底理解!

X86 Assembly/Other Instructions - Wikibooks, open books for an open world

これは、移植するターゲットによるのだが、通常はメモリマップドI/Oになると考えると、単なるメモリアクセスに置き換えても良い気がする。 ただし、ここではuncachedなアクセスにする必要があるだろう。ここではそこまで深く考えずに、実装の観点でそこはカバーできるものとした。 そうすると、単純なメモリアクセスに変更できる。

static inline uchar
inb(ushort port)
{
  uchar data;

  data = (*(volatile uchar *)(RISCV_IO_BASE + port));
  return data;
}

insl(int port, void *addr, int cnt)

inslは最初はよく分からなかったが、xv6のマニュアルを読むとしっかり書いてある。

http://www.cs.columbia.edu/~junfeng/11sp-w4118/lectures/boot.pdf

The implementation of insl (0412) is worth looking at more closely. Rep insl is
actually a tight loop masquerading as a single instruction. The rep prefix executes the
following instruction %ecx times, decrementing %ecx after each iteration. The insl
instruction reads a 32-bit value from port %dx into memory at address %edi and then
increments %edi by 4. Thus rep insl copies 4×%ecx bytes, in 32-bit chunks, from
port %dx into memory starting at address %edi.

x86にはrepという怪しげな記述子があり、これはECXレジスタが0になるまでデクリメントを繰り返し、当該命令を繰り返すらしい。xv6の実装は下記のようになっているので、

static inline void
insl(int port, void *addr, int cnt)
{
  asm volatile("cld; rep insl" :
               "=D" (addr), "=c" (cnt) :
               "d" (port), "0" (addr), "1" (cnt) :
               "memory", "cc");
}

こんな感じに変換できるのだろうか?

static inline void
insl(int port, void *addr, int cnt)
{
  int *addr_sl = (int *)addr;
  while ((cnt--) > 0) {
    *addr_sl = (*(volatile int *)(RISCV_IO_BASE + port));
    addr_sl++;
  }
}

参考になるサンプルプログラムがなかったので、よくわからない。ただし、この記述は結構いろんなところで利用されているようだ。ちょっと検索しただけでも、いろんなコードが出てきた。

80386 Programmer's Reference Manual -- Opcode REP

src/arch/x86/include/arch/io.h - chromiumos/third_party/coreboot - Git at Google

割り込み許可、不許可

x86計では、cli命令、sti命令というものが存在する。また、MIPSならばEI,DI命令というものが存在し、割り込みの許可、禁止を設定できる。

softwaretechnique.jp

今回、これをRISC-Vで実現しようとなれば、どのように書けばよいだろう?RISC-Vには、mie, mip, sie, sipというレジスタが存在しており、それぞれタイマー割り込みや、外部割込みの発生の許可、禁止を制御できる。

f:id:msyksphinz:20160327020029p:plain RISC-Vは、EI, DIというような、マスクや、割り込みの設定を維持しながら許可、禁止を制御できるようにはなっていないらしい。そうすると、これらのレジスタを直接書き換えると元に戻せなくなってしまうので、何らかのバックアップする手段を持っていたほうがよさそうだ。これには、mstatusのスタック型の割り込み許可、禁止機能が利用できそうだ。

f:id:msyksphinz:20160327020059p:plain

Visual Studio Codeがオープンソース化されたのでソースからビルド(成功)

以前Visual Studio Codeがオープンソース化されたときに、フルスクラッチでビルドしようとして失敗したのだった。

msyksphinz.hatenablog.com

あれからずいぶんと時間がたったが、結局フルスクラッチビルドできるようになったのだろうか?久しぶりに挑戦してみよう。

Visual Studio Codeのフルスクラッチビルドに挑戦

Visual Studio Codeのリポジトリは以下に格納されている。ビルドに挑戦した環境は、Ubuntu 15.10をVagrant上で動作させている。

github.com

インストールには、以下のWikiを参考にした。

Node.JSのビルド

Visual Studio CodeにはElectronが利用されており、ビルドにはNode.JSが必要になる。v4以上が必要ということで、なるべく最新版を利用するようにしたい。 オフィシャルからソースコードをダウンロードして、ビルドした。

Node.js

オフィシャルページからソースコードをダウンロードして、解凍し、通常のconfigure, make, make installの流れでインストールできた。

f:id:msyksphinz:20160326032017p:plain

tar xvfz node-v4.4.1.tar.gz
cd node-v4.4.1
./configure
make
sudo make install

Visual Studio Codeのビルド

これは、Visual Studio CodeのWikiを参考にした。

github.com

まずは、Wikiに書いてある通り、各種パッケージをインストールしておいた。

sudo apt-get -y install libx11-dev python fakeroot

そして、ビルドを実行する。

git clone https://github.com/microsoft/vscode
cd vscode
./scripts/npm.sh install --arch=x64

特にエラーもなくビルド終了できた。成功だ!

Visual Studio Codeを立ち上げる

ビルドに成功しても、バイナリファイルが見つからないのだが、これはスクリプトを読み出すことでVisual Studio Codeを実行できる。

~/vscode$ ./scripts/code.sh

しかし何も考えずに実行すると、ライブラリがないとエラーになった。

~/vscode$ ./scripts/code.sh
[18:05:43] Using gulpfile ~/vscode/gulpfile.js
[18:05:43] Starting 'electron'...
[18:05:43] Finished 'electron' after 472 μs
./.build/electron/electron: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

そこで、ライブラリをインストールする。

sudo aptitude install libnss3 libnss3-dev
./scripts/code.sh

これで起動できた!

f:id:msyksphinz:20160326032818p:plain

結論

Visual Studio Codeはフルスクラッチからビルドできるように改善された。