<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns="http://purl.org/rss/1.0/"
 xmlns:content="http://purl.org/rss/1.0/modules/content/"
 xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
 xmlns:admin="http://webns.net/mvcb/"
 xmlns:atom="http://www.w3.org/2005/Atom"
>
<channel rdf:about="http://blog.kmckk.com/">
<title>KMC Staff Blog</title>
<link>http://blog.kmckk.com/</link>
<description>JTAG-ICE デバッガベンダー、京都マイクロコンピュータ株式会社 (Kyoto Microcomputer Co., Ltd. ; KMC) スタッフのブログです。（現在スパムコメントがあまりにも多いため、半角英数字のみのコメント/トラックバック、国外の IP アドレスからのコメント、改行が 10 個以上あるコメントは受け付けない設定になってます。）
</description>
<dc:language>ja</dc:language>
<admin:generatorAgent rdf:resource="http://blog.livedoor.com/?v=2.0" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<items>
 <rdf:Seq>
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6205973.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6186582.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6146990.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6146771.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6146557.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6145442.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6145277.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6143564.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6093344.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6080763.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6032909.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/6032412.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/5951347.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/5799132.html" />
  <rdf:li rdf:resource="http://blog.kmckk.com/archives/5774305.html" />
 </rdf:Seq>
</items>
</channel>
<item rdf:about="http://blog.kmckk.com/archives/6205973.html">
<title>河田くんのバグ修正パッチがQEMU本家に取り込まれました</title>
<link>http://blog.kmckk.com/archives/6205973.html</link>
<description>実機では正しく動くプログラムが QEMU（ARM Cortex-R52 ターゲット）では動かないという例が見つかり、なかなか真の原因に辿りつけず（そればかりやっていたわけではありませんが）2 週間ぐらい悩んでいた所、とても優秀な後輩の河田くんがサクッとバグ修正パッチを本家に送...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2025-07-07T18:00:56+09:00</dc:date>
<dc:subject>qemu</dc:subject>
<content:encoded><![CDATA[実機では正しく動くプログラムが QEMU（ARM Cortex-R52 ターゲット）では動かないという例が見つかり、なかなか真の原因に辿りつけず（そればかりやっていたわけではありませんが）2 週間ぐらい悩んでいた所、とても優秀な後輩の河田くんがサクッとバグ修正パッチを本家に送ってくれて無事取り込まれました。感謝！<br>
<br>
<a href="https://gitlab.com/qemu-project/qemu/-/issues/3002">https://gitlab.com/qemu-project/qemu/-/issues/3002</a> （バグ報告）<br>
<br>
<a href="https://github.com/qemu/qemu/commit/0d0fc3f4658937fb81fcc16a89738e83bd8d4795">https://github.com/qemu/qemu/commit/0d0fc3f4658937fb81fcc16a89738e83bd8d4795</a> （コミット）<br>
<br>
以下は調査の過程やこのパッチの内容となります。<br>
<a href="http://blog.kmckk.com/archives/6205973.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6186582.html">
<title>glibcはstatic linkしてはいけない</title>
<link>http://blog.kmckk.com/archives/6186582.html</link>
<description>Ubuntu 20.4 LTS でビルドした Clang を 24.04 で実行した所、以下のようなエラーで動作しませんでした。

/home/kmc/test/aarch64/bin/clang: /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found (required by /home/kmc/test/aarch64/bin/clang)

...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2025-02-04T19:00:38+09:00</dc:date>
<dc:subject>Linux</dc:subject>
<content:encoded><![CDATA[Ubuntu 20.4 LTS でビルドした Clang を 24.04 で実行した所、以下のようなエラーで動作しませんでした。
<pre>
/home/kmc/test/aarch64/bin/clang: /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found (required by /home/kmc/test/aarch64/bin/clang)
</pre>
以前 18.04 でビルドした Clang が依存する libtinfo のバージョンが、20.04 から libtinfo6 に上がったため動作しないという事例があったのですが（この時は libtinfo5 をインストールで解決）、今回はシステムの共有ライブラリの互換性は失われていないはずなのに動作しないのです。<br>
<br>
<a href="http://blog.kmckk.com/archives/6186582.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6146990.html">
<title>LLVM18の驚異的な最適化はどのように実装されているのか調べてみました</title>
<link>http://blog.kmckk.com/archives/6146990.html</link>
<description>ずっと問題なく動いていたコードが LLVM 18 から動かなくなってしまったことをきっかけに始まった調査でしたが、気が付けばけっこうな分量になりました。

SoftFloatの未定義動作バグ（1）signedのunsignedな絶対値を求める際にINT_MIN
SoftFloatの未定義動作バグ（2）RISC-V...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2024-07-12T18:59:09+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[ずっと問題なく動いていたコードが LLVM 18 から動かなくなってしまったことをきっかけに始まった調査でしたが、気が付けばけっこうな分量になりました。<br>
<br>
<a href="http://blog.kmckk.com/archives/6145277.html">SoftFloatの未定義動作バグ（1）signedのunsignedな絶対値を求める際にINT_MIN</a><br>
<a href="http://blog.kmckk.com/archives/6145442.html">SoftFloatの未定義動作バグ（2）RISC-VのRV64Iではunsignedの32bit即値でも64bitレジスタの上位32bitが0とは限らない</a><br>
<a href="http://blog.kmckk.com/archives/6146557.html">RV64Iでunsignedの32bit値が符号拡張されないで関数にレジスタ渡しされるのはどういう時か？</a><br>
<a href="http://blog.kmckk.com/archives/6146771.html">SoftFloatの未定義動作バグ（3）そもそも単精度浮動小数点数演算をソフトウェアエミュレーションする関数の仮引数はfloatにするべき</a><br>
<br>
そして、コンパイラの最適化のバグではなく、コードにもともとあった問題が顕在化したという結論になりました。詳細は上記リンクを参照してください。<br>
<br>
その調査の過程で LLVM 18 の驚異的な最適化を目の当たりにしました。以下のように float を uint32_t として扱い、符号ビットを比較するコードが…
<pre>
    aSign = a >> 31;
    bSign = b >> 31;
    if ( aSign != bSign ) { ... }
</pre>
RV64I ターゲットでは uint32_t であっても常に 64 bit に符号拡張されるという RISC-V の呼び出し規約を利用し、（64 bit の）xor を取って符号ビット（bit 31 ではなく bit 63）が 1、つまり負の数ならば符号ビットが異なるので次にジャンプ（Branch Less Than Zero; bltz）というコードが生成されました。
<pre>
  xor         a2, a1, a0
  bltz        a2, 0x1c
</pre>
LLVM 17 までは、以下のように下位 32 bit を 31 bit 論理右シフト（Shift Right Logical Immediate Word; srliw）して比較（Branch Not Equal; bne）という素直なコードが出ていました。そのため問題のあるコードでも期待通り動作していたのです。
<pre>
  srliw       a2, a0, 0x1f
  srliw       a3, a1, 0x1f
  bne         a2, a3, 0x38
</pre>
こんな最適化、いったいどうやったら実現できるのでしょうか？調べてみました。<br>
<br>
<a href="http://blog.kmckk.com/archives/6146990.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6146771.html">
<title>SoftFloatの未定義動作バグ（3）そもそも単精度浮動小数点数演算をソフトウェアエミュレーションする関数の仮引数はfloatにするべき</title>
<link>http://blog.kmckk.com/archives/6146771.html</link>
<description>前々回の記事では

これを「未定義動作バグ」と呼ぶのが適切なのかは自信がありませんが、おそらくプログラマには 「uint32_t を 31 ビット右シフトした場合、bit 0 以外は全て 0 になり、0x0 か 0x1 のどちらかに必ずなる」という暗黙の仮定があったのではないかと思われ、...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2024-07-11T13:06:04+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[<a href="http://blog.kmckk.com/archives/6145442.html">前々回の記事</a>では
<blockquote>
これを「未定義動作バグ」と呼ぶのが適切なのかは自信がありませんが、おそらくプログラマには 「uint32_t を 31 ビット右シフトした場合、bit 0 以外は全て 0 になり、0x0 か 0x1 のどちらかに必ずなる」という暗黙の仮定があったのではないかと思われ、そうとは限らないという意味で未定義動作バグとしました。
</blockquote>
<a href="http://blog.kmckk.com/archives/6146557.html">前回の記事</a>では
<blockquote>
コンパイララインタイム関数は C 言語仕様の範疇ではなく、完全にコンパイラの実装と結びついたもの（コード生成の一部と考えられる）なので、なんでもありなのでしょう。
</blockquote>
<blockquote>
ではなぜ compiler-rt の関数は大丈夫なのか？という疑問が生まれますが、どうもレジスタ渡しされてきた値を一度スタックに書き込んで符号付きに変換して扱っているから大丈夫なようです。<br>
<br>
そもそも本来は __ltsf2 に渡ってくるのは float 型のようで、そのまま uint32_t で扱ってはいけないのかもしれません。
</blockquote>
などとごまかして終わらせてしまいましたが、ちゃんと調べました。<br>
<br>

<a href="http://blog.kmckk.com/archives/6146771.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6146557.html">
<title>RV64Iでunsignedの32bit値が符号拡張されないで関数にレジスタ渡しされるのはどういう時か？</title>
<link>http://blog.kmckk.com/archives/6146557.html</link>
<description>前回の記事「SoftFloatの未定義動作バグ（2）RISC-VのRV64Iではunsignedの32bit即値でも64bitレジスタの上位32bitが0とは限らない」の補足です。

RISCV RV64I では unsigned な 32 bit 値（uint32_t）であっても、常に汎用レジスタ上では符号拡張された形で扱われます。例え...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2024-07-10T18:59:10+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[前回の記事「<a href="http://blog.kmckk.com/archives/6145442.html">SoftFloatの未定義動作バグ（2）RISC-VのRV64Iではunsignedの32bit即値でも64bitレジスタの上位32bitが0とは限らない</a>」の補足です。<br>
<br>
RISCV RV64I では unsigned な 32 bit 値（uint32_t）であっても、常に汎用レジスタ上では符号拡張された形で扱われます。例えば f(uint32_t) 関数に f(0xc0000000) を渡した場合、第一引数が渡る a0（x10）レジスタには 0x00000000c0000000 ではなく 0xffffffffc0000000 が渡ります。Clang コンパイラもこの仕様を前提とした最適化を行っています。<br>
<br>
ならば、符号拡張されない形で 32 bit 値が関数にレジスタ渡しされてきたならば、それはバグではないか？という疑問が生まれます。そもそもこの値はどこから来たのでしょうか？調べてみました。<br>
<br>
<a href="http://blog.kmckk.com/archives/6146557.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6145442.html">
<title>SoftFloatの未定義動作バグ（2）RISC-VのRV64Iではunsignedの32bit即値でも64bitレジスタの上位32bitが0とは限らない</title>
<link>http://blog.kmckk.com/archives/6145442.html</link>
<description>前回の記事「SoftFloatの未定義動作バグ（1）signedのunsignedな絶対値を求める際にINT_MIN」の続きです。

前回の記事では肝心なことを書き忘れたのですが、libc の「fp ソフトウェアエミュレーション」とは、つまり libc でコンパイラランタイムライブラリ（GCC の libgcc ...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2024-07-05T15:44:10+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[前回の記事「<a href="http://blog.kmckk.com/archives/6145277.html">SoftFloatの未定義動作バグ（1）signedのunsignedな絶対値を求める際にINT_MIN</a>」の続きです。<br>
<br>
前回の記事では肝心なことを書き忘れたのですが、libc の「fp ソフトウェアエミュレーション」とは、つまり libc でコンパイラランタイムライブラリ（GCC の libgcc や LLVM の compiler-rt）の関数を実装しているということです。FPU が無いターゲットでは、コンパイラは fp 命令の代わりにこの関数を呼び出します。<br>
<br>
なぜこんな面倒なことをしているかというと、libgcc も compiler-rt も fenv.h を考慮せず、常に FE_TONEAREST で fp 演算を行うからだと思われます。現実的には FPU が無い CPU で丸め方式の考慮が必要になるようなプログラムを実行するケースは稀だと思いますが、NetBSD にはこだわりがあるのでしょう。（弊社もできる限り全てのサポートターゲットが標準に準拠した動作を行うコンパイラツールチェーン製品を目指しています。）<br>
<br>
<a href="http://blog.kmckk.com/archives/6145442.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6145277.html">
<title>SoftFloatの未定義動作バグ（1）signedのunsignedな絶対値を求める際にINT_MIN</title>
<link>http://blog.kmckk.com/archives/6145277.html</link>
<description>NetBSD の libc は FPU を持たないターゲット向けの fp（浮動小数点数）ソフトウェアエミュレーションに John R. Hauser 氏が開発している Berkeley SoftFloat のバージョン 2a を使用しています。
http://www.jhauser.us/arithmetic/SoftFloat.html

弊社のコンパイラツール...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2024-07-04T20:10:01+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[NetBSD の libc は FPU を持たないターゲット向けの fp（浮動小数点数）ソフトウェアエミュレーションに John R. Hauser 氏が開発している Berkeley SoftFloat のバージョン 2a を使用しています。<br>
<a href="http://www.jhauser.us/arithmetic/SoftFloat.html">http://www.jhauser.us/arithmetic/SoftFloat.html</a><br>
<br>
弊社のコンパイラツールチェーン製品 exeClang は NetBSD の libc を使用しているのですが、LLVM 18 版の開発中に RISC-V の RV64 IMA（noFPU）ターゲットをいつものように商用コンパイラテストスイートにかけると、新規 fail が 1 つ発生しました。<br>
<br>
その原因を追究して行く過程で、この SoftFloat の未定義動作（Undefined Behavior; UB）を 2 つ発見したので紹介します。今回はそのうち 1 つ目です。<br>
<br>
<a href="http://blog.kmckk.com/archives/6145277.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6143564.html">
<title>MSYS2のQEMUを使用する場合はUCRT64版を推奨</title>
<link>http://blog.kmckk.com/archives/6143564.html</link>
<description>MSYS2 を使用する場合、MinGW64 環境と UCRT64 環境の 2 つがあります。

MinGW64 は馴染み深い Microsoft Visual C++ の msvcrt を C RunTime（CRT）ライブラリに使用します。一方 UCRT64 は Windows 10 から使用可能な Universal CRT を使用します。（UCRT64 は 2020 年ご...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2024-06-27T14:05:25+09:00</dc:date>
<dc:subject>qemu</dc:subject>
<content:encoded><![CDATA[MSYS2 を使用する場合、MinGW64 環境と UCRT64 環境の 2 つがあります。<br>
<br>
MinGW64 は馴染み深い Microsoft Visual C++ の msvcrt を C RunTime（CRT）ライブラリに使用します。一方 UCRT64 は Windows 10 から使用可能な Universal CRT を使用します。（UCRT64 は 2020 年ごろから開発が始まった比較的新しい環境です。）<br>
<br>
今まではどちらも同じようなものだと思っていたので惰性で MinGW64 を使い続けてきましたが、同じバージョンの QEMU が UCRT 版（mingw-w64-ucrt-x86_64-qemu）は期待通り動くのに、MinGW64 版（mingw-w64-x86_64-qemu）は動かないケースがありました。今後は特別な理由が無い限り UCRT64 環境を使おうと思います。<br>
<br>
詳細は以下になります。<br>
<a href="http://blog.kmckk.com/archives/6143564.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6093344.html">
<title>GNU ldとLLVM lldのロケーションカウンタの扱いの違い</title>
<link>http://blog.kmckk.com/archives/6093344.html</link>
<description>従来は Linux や Apple などのリッチ OS のアプリ向けというイメージだった LLVM の高速リンカ lld ですが、LLVM 17 で GNU ld との互換性がほぼ完璧になり、AArch64/ARM/RISC-V のベアメタルツールチェーンでも GNU ld を置き換えできることが確認できました。そこで弊社の ...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2023-12-06T20:24:49+09:00</dc:date>
<dc:subject>LLVM</dc:subject>
<content:encoded><![CDATA[従来は Linux や Apple などのリッチ OS のアプリ向けというイメージだった LLVM の高速リンカ lld ですが、LLVM 17 で GNU ld との互換性がほぼ完璧になり、AArch64/ARM/RISC-V のベアメタルツールチェーンでも GNU ld を置き換えできることが確認できました。そこで弊社の SOLID もリンクの高速化や Clang での LTO などを期待して  lld 対応を進めているのですが、その時に 1 点だけ非常にわかりにくい非互換性に悩まされたのでメモしておきます。<br>
<br>
<a href="http://blog.kmckk.com/archives/6093344.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6080763.html">
<title>MSYS2のバグ？（Bad address）</title>
<link>http://blog.kmckk.com/archives/6080763.html</link>
<description>業務でシェルスクリプトを書いていて、非常に不可解な現象に遭遇しました。いまだに未解決ですが、メモを残しておきます。

以下が、現象が発生する最少シェルスクリプトとなります。

#!/bin/bash -xe

export LIBFLAGS=&quot;c:/ d:/&quot;

/c/msys64/mingw64/bin/gcc.exe -v &amp;&gt; XXX...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2023-10-26T18:40:13+09:00</dc:date>
<dc:subject>メモ</dc:subject>
<content:encoded><![CDATA[業務でシェルスクリプトを書いていて、非常に不可解な現象に遭遇しました。いまだに未解決ですが、メモを残しておきます。<br>
<br>
以下が、現象が発生する最少シェルスクリプトとなります。
<pre>
#!/bin/bash -xe

export LIBFLAGS="c:/ d:/"

/c/msys64/mingw64/bin/gcc.exe -v &> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.txt
</pre>
<a href="http://blog.kmckk.com/archives/6080763.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6032909.html">
<title>RustでAArch64（QEMU）ベアメタルプログラミング</title>
<link>http://blog.kmckk.com/archives/6032909.html</link>
<description>私は担当ではないので詳しくないのですが、弊社では Rust の開発環境を提供しています。
https://www.kmckk.co.jp/pdf/20211020_solid_press.pdf

それとは特に関係なく、諸事情で Rust で書かれたライブラリをベアメタル環境で使う必要が出てきたので、遅ればせながら Rust ...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2023-04-28T18:45:53+09:00</dc:date>
<dc:subject>Rust</dc:subject>
<content:encoded><![CDATA[私は担当ではないので詳しくないのですが、弊社では Rust の開発環境を提供しています。<br>
<a href="https://www.kmckk.co.jp/pdf/20211020_solid_press.pdf">https://www.kmckk.co.jp/pdf/20211020_solid_press.pdf</a><br>
<br>
それとは特に関係なく、諸事情で Rust で書かれたライブラリをベアメタル環境で使う必要が出てきたので、遅ればせながら Rust の勉強を始めました。<br>
<br>
まずはこのチュートリアルをやってみた所、予想外にいろいろハマってしまい、情報も少なくて困ったので、うまくいった方法をメモしておきます。（私も初心者なので、このやり方が正しいとは限りません。）<br>
<br>
AArch64 Bare-Metal program in Rust<br>
<a href="https://lowenware.com/blog/aarch64-bare-metal-program-in-rust/">https://lowenware.com/blog/aarch64-bare-metal-program-in-rust/</a><br>

<a href="http://blog.kmckk.com/archives/6032909.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/6032412.html">
<title>MSYS2でQEMU 7.1をビルド</title>
<link>http://blog.kmckk.com/archives/6032412.html</link>
<description>このブログでも何度か取り上げてきましたが、QEMU の Windows バイナリ（x64）のビルドは、以前はとても大変でした。今回、とある事情で数年ぶりに Xilinx QEMU の git HEAD（QEMU 7.1.0 ベース）をビルドする必要がでてきたので調査したところ、以前作った Xilinx QEMU 2020...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2023-04-26T18:52:48+09:00</dc:date>
<dc:subject>qemu</dc:subject>
<content:encoded><![CDATA[このブログでも何度か取り上げてきましたが、QEMU の Windows バイナリ（x64）のビルドは、以前はとても大変でした。今回、とある事情で数年ぶりに Xilinx QEMU の git HEAD（QEMU 7.1.0 ベース）をビルドする必要がでてきたので調査したところ、以前作った Xilinx QEMU 2020.3（QEMU 5.0.50 ベース）のビルド環境ではライブラリが古いためビルドできず、アップデートも困難な状態でした。<br>
<br>
最終的に、最も王道である MSYS2 でビルドが成功し、正常動作が確認できました。その時のメモです。<br>
<br>
<a href="http://blog.kmckk.com/archives/6032412.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/5951347.html">
<title>Thread Local StorageをOSに頼らず実装する方法</title>
<link>http://blog.kmckk.com/archives/5951347.html</link>
<description>特定の OS を前提としないベアメタルのツールチェーン（いわゆる aarch64-unknown-elf のようなターゲット）に付属するライブラリは、マルチスレッド関係のライブラリの排他制御などが全て OFF になった状態です。pthread などのスレッドライブラリを前提にすることは当然で...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2022-07-28T19:00:39+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[特定の OS を前提としないベアメタルのツールチェーン（いわゆる aarch64-unknown-elf のようなターゲット）に付属するライブラリは、マルチスレッド関係のライブラリの排他制御などが全て OFF になった状態です。pthread などのスレッドライブラリを前提にすることは当然できませんが、Thread Local Storage（TLS）だけならば OS に依存しない形で実装でき、かつ OS を使う場合は無変更でライブラリ関数のスレッドセーフ化が可能なのではないか？と思いつき、調査した時のメモです。<br>
<br>
<a href="http://blog.kmckk.com/archives/5951347.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/5799132.html">
<title>RustからRTOS APIを使う</title>
<link>http://blog.kmckk.com/archives/5799132.html</link>
<description>最近Rustという新しいプログラミング言語が多くの分野で注目を浴びています。RustはC++のような低レベルなコンパイル型言語であり高い効率で動作する一方、強力な型システムやメモリ安全性を保証するための仕組みを備えており、バグの少ないコードを書くことができます。本記...</description>
<dc:creator>kwdkk</dc:creator>
<dc:date>2021-06-14T15:54:30+09:00</dc:date>
<dc:subject>Rust</dc:subject>
<content:encoded><![CDATA[<p>最近<a href="https://www.rust-lang.org/ja/">Rust</a>という新しいプログラミング言語が多くの分野で注目を浴びています。RustはC++のような低レベルなコンパイル型言語であり高い効率で動作する一方、強力な型システムやメモリ安全性を保証するための仕組みを備えており、バグの少ないコードを書くことができます。本記事では、TOPPERSカーネルや弊社のSOLID-OS上でRustで書かれたプログラムを動かし、カーネルAPIを使用する方法を紹介します。</p>
<a href="http://blog.kmckk.com/archives/5799132.html">続きを読む</a>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.kmckk.com/archives/5774305.html">
<title>GCC無しでClangクロスCコンパイラ（RISCV64）をビルドして自動ベクトル化を試す</title>
<link>http://blog.kmckk.com/archives/5774305.html</link>
<description>GCC の場合、ホストの C++ コンパイラのみ（通常は GCC）で、Binutils と GCC のソースコードから完全な C/C++ クロスコンパイラをビルドすることが可能です。

これまで Clang は GCC に依存しており、LLVM プロジェクトのソースコードのみで完全なクロスコンパイラをビルド...</description>
<dc:creator>kmckk</dc:creator>
<dc:date>2021-04-14T17:35:55+09:00</dc:date>
<dc:subject>Clang</dc:subject>
<content:encoded><![CDATA[GCC の場合、ホストの C++ コンパイラのみ（通常は GCC）で、Binutils と GCC のソースコードから完全な C/C++ クロスコンパイラをビルドすることが可能です。<br>
<br>
これまで Clang は GCC に依存しており、LLVM プロジェクトのソースコードのみで完全なクロスコンパイラをビルドすることはできない（そのため、GCC のヘッダやライブラリをそのまま使うしかない）という認識でした。この誤解は、CMake が完全な（a.out を生成可能な）C/C++ コンパイラを要求するので、Clang のランタイムライブラリである compiler-rt を Clang 自身でビルドする方法がわからなかったためです。一つでも GCC でライブラリをビルドしてしまうと、そのライブラリは GCC のヘッダに依存することになるので、他のライブラリも全て同じ GCC でビルドしなければなりません。<br>
<br>
しかし最近いろいろ調べていて、実はそれが可能であることがわかりました。<br>
ただし、以下の制限があります。（この記事では RISC-V をターゲットとします。他のターゲットでは以下の制限は無い可能性があります。）<br>
<ul>
<li>LLVM のリンカ LLD は RISC-V のデフォルトである -mrelax オプション（Linker optimization/relaxation）のサポートが完全ではないなど、様々な問題があるため、リンカのみ Binutils の GNU ld を使用します。</li>
<li>LLVM の C++ ランタイム実装 libc++abi と C++ ライブラリ libc++ が newlib ではビルドできないようなので、今回は C コンパイラのみビルドします。（libc++abi の実装に使用される C++ 例外の実装  libunwind はビルド可能ですが、C の場合は不要なので今回は割愛します。）</li>
<li>RISC-V 命令セットシミュレータの spike と一緒に使用する pk カーネルが clang ではビルドできないようなので、spike/pk は今回はビルドせず、以前の環境で GCC を使ってビルドしたものを使用します。（OVPsim の無償版は現在 V 拡張をサポートしていない問題があります。）</li>
</ul>
<br>
<br>
<a href="http://blog.kmckk.com/archives/5774305.html">続きを読む</a>
]]>
</content:encoded>
</item>

</rdf:RDF>
