2023年12月06日
従来は Linux や Apple などのリッチ OS のアプリ向けというイメージだった LLVM の高速リンカ lld ですが、LLVM 17 で GNU ld との互換性がほぼ完璧になり、AArch64/ARM/RISC-V のベアメタルツールチェーンでも GNU ld を置き換えできることが確認できました。そこで弊社の SOLID もリンクの高速化や Clang での LTO などを期待して lld 対応を進めているのですが、その時に 1 点だけ非常にわかりにくい非互換性に悩まされたのでメモしておきます。
続きを読む
続きを読む
2023年10月26日
2023年04月28日
私は担当ではないので詳しくないのですが、弊社では Rust の開発環境を提供しています。
https://www.kmckk.co.jp/pdf/20211020_solid_press.pdf
それとは特に関係なく、諸事情で Rust で書かれたライブラリをベアメタル環境で使う必要が出てきたので、遅ればせながら Rust の勉強を始めました。
まずはこのチュートリアルをやってみた所、予想外にいろいろハマってしまい、情報も少なくて困ったので、うまくいった方法をメモしておきます。（私も初心者なので、このやり方が正しいとは限りません。）
AArch64 Bare-Metal program in Rust
https://lowenware.com/blog/aarch64-bare-metal-program-in-rust/
続きを読む
https://www.kmckk.co.jp/pdf/20211020_solid_press.pdf
それとは特に関係なく、諸事情で Rust で書かれたライブラリをベアメタル環境で使う必要が出てきたので、遅ればせながら Rust の勉強を始めました。
まずはこのチュートリアルをやってみた所、予想外にいろいろハマってしまい、情報も少なくて困ったので、うまくいった方法をメモしておきます。（私も初心者なので、このやり方が正しいとは限りません。）
AArch64 Bare-Metal program in Rust
https://lowenware.com/blog/aarch64-bare-metal-program-in-rust/
続きを読む
2023年04月26日
このブログでも何度か取り上げてきましたが、QEMU の Windows バイナリ（x64）のビルドは、以前はとても大変でした。今回、とある事情で数年ぶりに Xilinx QEMU の git HEAD（QEMU 7.1.0 ベース）をビルドする必要がでてきたので調査したところ、以前作った Xilinx QEMU 2020.3（QEMU 5.0.50 ベース）のビルド環境ではライブラリが古いためビルドできず、アップデートも困難な状態でした。
最終的に、最も王道である MSYS2 でビルドが成功し、正常動作が確認できました。その時のメモです。
続きを読む
最終的に、最も王道である MSYS2 でビルドが成功し、正常動作が確認できました。その時のメモです。
続きを読む
2022年07月28日
特定の OS を前提としないベアメタルのツールチェーン（いわゆる aarch64-unknown-elf のようなターゲット）に付属するライブラリは、マルチスレッド関係のライブラリの排他制御などが全て OFF になった状態です。pthread などのスレッドライブラリを前提にすることは当然できませんが、Thread Local Storage（TLS）だけならば OS に依存しない形で実装でき、かつ OS を使う場合は無変更でライブラリ関数のスレッドセーフ化が可能なのではないか？と思いつき、調査した時のメモです。
続きを読む
続きを読む
2021年06月14日
2021年04月14日
GCC の場合、ホストの C++ コンパイラのみ（通常は GCC）で、Binutils と GCC のソースコードから完全な C/C++ クロスコンパイラをビルドすることが可能です。
これまで Clang は GCC に依存しており、LLVM プロジェクトのソースコードのみで完全なクロスコンパイラをビルドすることはできない（そのため、GCC のヘッダやライブラリをそのまま使うしかない）という認識でした。この誤解は、CMake が完全な（a.out を生成可能な）C/C++ コンパイラを要求するので、Clang のランタイムライブラリである compiler-rt を Clang 自身でビルドする方法がわからなかったためです。一つでも GCC でライブラリをビルドしてしまうと、そのライブラリは GCC のヘッダに依存することになるので、他のライブラリも全て同じ GCC でビルドしなければなりません。
しかし最近いろいろ調べていて、実はそれが可能であることがわかりました。
ただし、以下の制限があります。（この記事では RISC-V をターゲットとします。他のターゲットでは以下の制限は無い可能性があります。）
続きを読む
これまで Clang は GCC に依存しており、LLVM プロジェクトのソースコードのみで完全なクロスコンパイラをビルドすることはできない（そのため、GCC のヘッダやライブラリをそのまま使うしかない）という認識でした。この誤解は、CMake が完全な（a.out を生成可能な）C/C++ コンパイラを要求するので、Clang のランタイムライブラリである compiler-rt を Clang 自身でビルドする方法がわからなかったためです。一つでも GCC でライブラリをビルドしてしまうと、そのライブラリは GCC のヘッダに依存することになるので、他のライブラリも全て同じ GCC でビルドしなければなりません。
しかし最近いろいろ調べていて、実はそれが可能であることがわかりました。
ただし、以下の制限があります。（この記事では RISC-V をターゲットとします。他のターゲットでは以下の制限は無い可能性があります。）
- LLVM のリンカ LLD は RISC-V のデフォルトである -mrelax オプション（Linker optimization/relaxation）のサポートが完全ではないなど、様々な問題があるため、リンカのみ Binutils の GNU ld を使用します。
- LLVM の C++ ランタイム実装 libc++abi と C++ ライブラリ libc++ が newlib ではビルドできないようなので、今回は C コンパイラのみビルドします。（libc++abi の実装に使用される C++ 例外の実装 libunwind はビルド可能ですが、C の場合は不要なので今回は割愛します。）
- RISC-V 命令セットシミュレータの spike と一緒に使用する pk カーネルが clang ではビルドできないようなので、spike/pk は今回はビルドせず、以前の環境で GCC を使ってビルドしたものを使用します。（OVPsim の無償版は現在 V 拡張をサポートしていない問題があります。）
続きを読む
2021年02月19日
Binutils や GCC は、Ubuntu 上で Windows で動作する、組み込み向け（RISC-V など）のコンパイラツールチェーンを簡単にビルドできます（カナディアンクロスビルド）。configure の際に --target=riscv64-unknown-elf --host=x86_64-w64-mingw32 --build=x86_64-pc-linux-gnu を指定するだけで、後は基本的にネイティブと同じです。この時、Ubuntu 上（x86_64-pc-linux-gnu）で動作するクロスの x86_64-w64-mingw32-gcc（g++）でビルドが行われるという仕組みです。
Clang の場合、CMake でどのように設定すれば良いのかとか、Windows バイナリを生成可能な clang が Ubuntu 上に見当たらなかった（clang をビルドするには、MinGW gcc ではなく、clang が必要）などの理由により、これまでは VisualStudio を使って Windows 上でビルドしていました。
今回、以下の記事で llvm-mingw の存在を知り、無事カナディアンクロスビルドに成功しました。
続きを読む
Clang の場合、CMake でどのように設定すれば良いのかとか、Windows バイナリを生成可能な clang が Ubuntu 上に見当たらなかった（clang をビルドするには、MinGW gcc ではなく、clang が必要）などの理由により、これまでは VisualStudio を使って Windows 上でビルドしていました。
今回、以下の記事で llvm-mingw の存在を知り、無事カナディアンクロスビルドに成功しました。
続きを読む
2021年02月05日
職場の開発 PC が AMD Ryzen 9 5950X（16 コア 32 スレッド）RAM 32GB になったのですが、これまで 1 時間以上かかっていたビルドが数分で終わるようになったので劇的に効率が上がりました。Release ビルドならば 16 並列で CPU ほぼ 100% 使い切りメモリも足りているようです。Debug ビルドは 8 並列ぐらいまで落としてもメモリ不足で失敗しますが、何回か繰り返すと最後まで終わるので、デバッグ時なら許容範囲かなという感じです。LLVM の開発をするならば、できれば RAM は 64GB 欲しい所ですね。
新規にビルド環境を作ったので、その時のメモです。
続きを読む
新規にビルド環境を作ったので、その時のメモです。
続きを読む
2020年11月27日
2020年11月19日
追記：本記事の内容は C++98 から有効であるとコメント欄にて教えていただきました。情報提供に感謝いたします。
GCC でコンパイル時に -Wall -Wextra の 2 オプションを付けるというのは非常に一般的です。この場合、以下のように未使用の関数引数には警告が出ます。
続きを読む
GCC でコンパイル時に -Wall -Wextra の 2 オプションを付けるというのは非常に一般的です。この場合、以下のように未使用の関数引数には警告が出ます。
$ cat test.c
void f(int x) {}
void g(int x) {}
int main()
{
f(10);
g(10);
return 0;
}
$ gcc -Wall -Wextra test.c
test.c: In function ‘f’:
test.c:1:12: warning: unused parameter ‘x’ [-Wunused-parameter]
void f(int x) {}
^
test.c: In function ‘g’:
test.c:2:12: warning: unused parameter ‘x’ [-Wunused-parameter]
void g(int x) {}
^
しかし、例えばコールバックとして渡す関数（ハンドラ）のように、引数を全部使わない関数というのはよくあります。続きを読む
2020年11月17日
以前、「GCCの最適化による予期せぬ無限ループの発生」という記事を書きました。この時は -fno-builtin-malloc や __asm __volatile("":::"memory"); などで対策できました。
しかし今回、現状最新の GCC 10 で、memset、しかもナイーブな *(char *)s++ = (char)c; みたいな実装ではなく、NetBSD の本格的な実装のもので発生し、-fno-builtin や -fno-builtin-memset、-ffreestanding などでも抑制できず、-fno-tree-loop-distribute-patterns というあまり一般的ではないオプションが必要になりました。
これは一見 GCC のオプションが効いてない、バグのように思えますが、調べて見ると GCC の仕様に根差した問題であることがわかりました。
続きを読む
しかし今回、現状最新の GCC 10 で、memset、しかもナイーブな *(char *)s++ = (char)c; みたいな実装ではなく、NetBSD の本格的な実装のもので発生し、-fno-builtin や -fno-builtin-memset、-ffreestanding などでも抑制できず、-fno-tree-loop-distribute-patterns というあまり一般的ではないオプションが必要になりました。
これは一見 GCC のオプションが効いてない、バグのように思えますが、調べて見ると GCC の仕様に根差した問題であることがわかりました。
続きを読む
