スタティックリンクでもPIE(Position Independent Executable)
PIEとは PIE(Position Independent Executable)はプログラムをロードするアドレスが固定ではない実行ファイルです。OSはロードアドレスをランダム化することで安全性を上げることができます。 gccに-pieというオプションがかなり昔からありましたが、単にこのオプションをつけるだけでPIEとして実行できるわけではなく、実行直前にダイナミックリンカがアドレスを解決する必要があったので、スタティックリンクした場合にはPIEにはなりませんでした。 しかし、最近gccに-static-pie というオプションがいつの間にか追加されていることに気がつきました。 hello worldでmain関数のアドレスを調べてみる AArch64のUbuntu 22.04を使用しています。 テストプログラムはこちら。
RISC-V勉強会で『「RISC-V原典」の出版当時と現在のRISC-V：進化と変化のポイント』を発表しました
RISC-V勉強会@Online 2023/03/16 (木)に登壇して2つの話をしました。 そのうちのひとつがこちら。 「RISC-V原典」の出版当時と現在のRISC-V：進化と変化のポイント 発表スライド 動画 次の発表者の@a4lg さんがもっと突っ込んだ話をしてくれました。そのスライドのリンクを貼っておきます。 RISC-Vの仕様とそのステータス一覧 最近策定された(Rafified)拡張一覧 参考 RISC-VのExtensionの最近の状況を知るのはこの記事がよさそうです。 RISC-V Instruction Set Architecture Extensions: A Survey 関連
親切な人だと思ったらあやしいbotだった話
私は英会話の勉強のために毎日NHKの語学アプリで「ラジオ英会話」の番組を聴いています。 そして、復習をかねて、書き取ったノートを #英語 のタグをつけてtweetするのを日課にしています。 今日のできごとを記録しておきます。 該当するツイートは削除してしまいました。これにつけられた引用リツイートとリプライに含まれているリンクが危険なものである可能性が高いと判断し、他の人が誤って踏まないようにするためです。 その内容はこちら。 I went to the art gallery only to find that it was closed for a whole day. Many luxury cars are stolen, never to be seen again. After 3 attempts, he finally passed the driving test. ラジオ
昔のFPUはCPUと別チップだったという話
「CPUで浮動小数点演算はFPUで行います。」と書かれていたとして、これをFPUって何？と思う若者がいるかもしれません。FPU( Floating-Point Unit)は昔はCPUとは別のチップになっていて、FPUコプロセッサと呼ばれていました。 組み込み用のマイクロコントローラを除いては、現代ではFPUはCPUに内蔵されているが普通です。FPUコプロセッサのチップはもうすっかり見なくなりました。 以下、記憶の範囲内で書いています。不正確なところがあったらごめんなさい。 パソコン向けCPUでの話 パソコン用のCPUではFPUが内蔵されたのはintelのCPUで言うと80486からです。それまでのパソコンのマザーボードにはFPUを挿すためソケットが用意されていて、必要な人は別途FPUコプロサッサを買って取り付けるということをしていました。 その頃に、FPUコプロサッサをつけると〇〇のアプリ
Linuxでスレッドのコンテキスト切り替えのたびにFPUのレジスタはメモリに保存されるのか
Linuxでスレッドのコンテキスト切り替えのたびにFPUのレジスタはメモリに保存されるのか？ シングルコアプロセッサしかなかった時代とマルチコアの時代で挙動が変わっています。 chatGPTに聞いてみた 間違えたことを言ったと気がついたら、すぐに謝ってくれるのはいい奴ですね、 スクリーンショットでは見にくいので、実際の内容を以下に貼り付けました。 In Linux kernel context switch does it save all FPU regsters each time? In Linux, the kernel does not save all floating-point unit (FPU) registers every time a context switch occurs. This is because saving and restoring the F
Unix/Linuxのリンカーはなぜldという名前なのか
素朴な疑問 Unix/Linuxのリンカーはなぜldという名前なのでしょうね。 逆に私の知る限りではUnix/Linuxの流れをくむ物以外ではリンカーをldとは呼ばないです。1980年代のMS-DOSではアセンブラとリンカーが付属していましたが名前はそれぞれasm.exe, link.exe でした。 私が触ったことのある商用のコンパイラツールチェーンでもリンカーはlinkっぽい名前でした。 chatGPTに聞いてみました。 "link editor" の略だって。本当かなあ。 Google検索ではこれが見つかりました。 loader説とlink-editor説がありますね。 "Linker and Loaders" という書籍とそのPDFを見つけました。 私の大胆な仮説 コンピュータの黎明期までさかのぼって想像してみます。 当時はメモリは非常に高価だったので、実行するプログラムに対して十
UEFIの歴史の雑なまとめとItaniumの思い出
前回の記事を書いたら、ありがたいことに色々な情報を教えてもらうことができました。「まず情報を出すと情報を得られる」"give & take" の典型ですね。 UEFIの雑なまとめ IntelとHPが共同で開発していた次世代64bit CPUのItanium向けのブートローダーとしてMicrosoftを巻き込んで開発されたのがEFI。 EFIはアーキテクチャには依存しないように設計されていた。 EFI v1.x はIntelに所有権があったが、Unified EFI Forumにそれを移管し、v2.x にするとともにUEFIと改名した。 UEFIはx86_64, aarch64などで採用され、MIPS, RISC-Vもそれに続くと思われている。 だいたいWikipediaに書いてある。 @oruminさん 「UEFI の reference のアプリケーション開発 SDK である EDK2
UEFIから起動するイメージの先頭が"MZ"である歴史的理由
RISC-Vのカーネルイメージのエントリーポイント kernelvmのrisc-vのチャネルで「riscv環境におけるlinuxのカーネルがロードされた直後からどう動くのかを知りたい。どこのコードから読めばよいか」という質問があり、あれこれ調べるうちにここだということが判明しました。 #ifdef CONFIG_EFI /* * This instruction decodes to "MZ" ASCII required by UEFI. */ c.li s4,-13 j _start_kernel どうもEFIで起動するイメージの先頭はASCIIコードで"MZ"となっている必要があるようです。 "EFI MZ" でいろいろ検索 どうやら、EFIで起動するイメージは(EFI Application)はPE(Portable Executable)というWindowsの実行形式と同じヘッダ
クロスコンパイル環境での逆アセンブル表示にはllvm-objdumpが便利
前回の記事 のように、複数のアーキテクチャ向けにクロスコンパイルした場面では逆アセンブル表示するのにllvm-objdumpを使うのが便利です。 Debian/Ubuntuでは sudo apt install llvm でインストールできます。 マルチアーキテクチャに対応するllvm-objdump ELFのヘッダ情報でアーキテクチャ種別を判別してくれるので、明示的にアーキテクチャを指定する必要がありません。gcc系のobjdumpだとアーキテクチャごとに別々のものを使う必要がありました。 $ llvm-objdump -d x86_64/a.out |head -20 x86_64/a.out: file format elf64-x86-64 Disassembly of section .text: 0000000000201eb0 <_start>: 201eb0: 48 31
zig cc がクロスコンパイルに便利な理由
#include <stdio.h> int main() { printf("Hello, world.\n"); return 0; } $ mkdir x86_64 $ mkdir aarch64 $ mkdir riscv64 $ (cd x86_64 && zig cc -target x86_64-linux-musl ../hello.c) $ (cd aarch64 && zig cc -target aarch64-linux-musl ../hello.c) $ (cd riscv64 && zig cc -target riscv64-linux-musl ../hello.c) $ ls -l */a.out -rwxrwxr-x 1 koba koba 35608 Jan 18 10:07 aarch64/a.out -rwxrwxr-x 1 koba koba
Zigでコンパイルエラーになって書き方がわからないとき
Zig言語は型に厳しい Zigは型に関して厳しい言語です。 以下のようなコードを書いたときに、たぶん型変換のことでエラーになるだろうなあと思いつつコンパイルしてみると const std = @import("std"); const expect = std.testing.expect; fn func(x: i32) u8 { return x & 0xff; } test "truncate" { try expect(func(0x1234) == 0x34); } $ zig test a.zig a.zig:5:14: error: expected type 'u8', found 'i32' return x & 0xff; ~~^~~~~~ a.zig:5:14: note: unsigned 8-bit int cannot represent all possibl
5分でざっと理解するZig言語
Zig言語の話をするときに、初めての人にざっと読んでもらうためのページ。 Zig言語とは 静的型付きのコンパイル言語。C言語と同じ立ち位置。 本家 ziglang.org のoverview 日本語 Wikipedia Wikipedia 英語版 ドキュメント 標準ライブラリのリファレンス 現在の状況 まだ開発中で正式リリースには至っていない。なのでまだ破壊的変更はあり得る。 記事を書いた時点の安定版タグは0.10.0。 公式なパッケージマネージャはまだない。[1](非公式なものは複数存在する) ** 2023/08/15 追記 ** 安定版0.11.0のリリースとともに公式版パッケージマネージャが利用可能になりました。 私が考えたキャッチコピー 「C言語が誕生したのは1972年。Zig言語はそれを2020年代の知見で再構成するもの。50年分の進化!!」 "C but with the p
言語のスレッド実装の雑な話(Green threadからGoのgoroutineまで)
Twitterで "green thread" という単語をたまたま見かけたので、知っていることをつぶやいたよ。 Green thread 言語のスレッドとOSのスレッドの関係 N:1 mapping 言語のスレッドの全てがひとつのOSのスレッドの上で実行されるもの。その代表が上記のJavaのgreen thread。 OSのシステムコールを呼ぶときには必ずnonblockingモードを使い、EAGAIN または EWOULDBLOCKが返ってきたときには他のスレッドの実行権に譲るようにする必要がある。うっかりシステムコールでブロックされてしまうと、全部のスレッドが巻き添えになって動けなくなる。 スレッドの生成やコンテキストの切り替えは軽い。しかし、マルチコアを生かすことができないため、シングルコアの環境でのみ使用される。 1:1 mapping OSのスレッドと言語のスレッドが1対1対応
RISC-Vが面白くなってきたぞ
(雑に書いている戯言であることを最初に断っておきます。あくまで個人の感想です。) 実は私は今までRISC-Vには懐疑的だったのですが、最近の状況を知って考えを改めました。 RISC-Vとは RISC-V（リスク ファイブ）とはオープンソースライセンスで提供されている命令セットアーキテクチャ (ISA)です。 研究にも使うことができるし、実際に多くの半導体メーカーがこの仕様に基づいたCPUを開発、出荷しています。 多くのオープンソースのOSやツールチェインもすでにRISC-Vに対応しています。 私が懐疑的だった理由 RISC-Vはオープンソースであるゆえ、自由に拡張することができます。そのため様々な派製品が登場しています。シンプルな組み込み用のマイクロコントローラからパソコン用、サーバ用、HPC用など広い分野に渡ります。 かつてRISCの考え方にもとづいて開発されたMIPSというCPUがあり
ZigでLinuxのepollとsignalfdのシステムコールを使うサンプルプログラム
Zig Advent Calendar 2022 に参加しています。 あるプログラムを作ろうと思ったのですが、それにはepollとsignalfdのシステムコールを使うのが良さそうだということがわかりました。これらのシステムコールを使うのは初めてだったのでまずは理解のために簡単なサンプルプログラムを作りました。そしてせっかくなのでそれをZig言語で書き直しました。 システムコール epoll について epollはLinuxでのI/Oイベントの通知のしくみです。これを使って複数の入出力を待つことができます。似たものにselectやpollがありますが、epollはそれらの中でも後発で、他のものにあった欠点を解決し柔軟性も性能も高いものになっています。なので、これから新規に作るならばepollを使うのがよいでしょう。なお、Zig言語のライブラリのstd.os.linuxではselectはサポ
音声コーデックLyraをビルドして試してみた
先日の時雨堂さんのオンラインイベントで、新しい音声コーデック Lyra によるWebRTCのリアルタイム通信を体験させていただきました。音質は高いわけではないが他のWeb会議システムと同じくらいで、音声通信のビットレートのグラフをみるとあまりの低さに驚きました。 それで興味を持ったのでLyraを自分でも試してみることにしました。 Lyra コーデック Google が開発したspeech(通話)用のコーデックです。機械学習を応用することで今までにないほどの低ビットレートを実現しています。 TensorFlow Lite を使用しています。 ビルド ビルドするにはx86_64のLinuxを使いました。Ubuntu 22.04 arm64のLinuxではビルドできません。またメモリが1GBしかない無料の仮想マシンでもビルドできませんでした。 今回使ったのは古いMacbook Air 2011年
Zig言語のドキュメントを見て「なるほど!」と思ったところ
前回の続き。 ちょっとZig言語が面白そうです。まだあまりzigでコードは書いていないのですが、ドキュメントやソースコードをながめて思ったことを書き散らかしてみます。 (他の人がすでに書いていることはなるべく書かない) オブジェクト指向でなくてデータ指向 C言語に後にC言語っぽい文法の言語はたくさん出てきました。C++, Java, C#, Go, Rustなど。 C++やJavaはオブジェクト指向の考え方を取り込んだもので、GoやRustはいきすぎたオブジェクト指向を反省して、interface とか trait とか良いところだけを抽出した感じになっています。(個人の感想です) Zigには純粋にC言語からの改善をしていて、オブジェクト指向の香りがあまりしません。 むしろ「データ指向設計」(Data-Oriented Design)が意識されているらしいです。 紹介してもらったこの動画が
期待の映像コーデックAV1についての噂のまとめ
** 2023/02/02追記。 この記事を書きました。 ** 追記ここまで 映像コーデックとしてH.264の次を担うものがなかなか普及しない状態でしたが、そろそろAV1が水平線に見えてきたかな。(2022年4月の情報) AV1とは wikipadia のAV1のページ "AV1（AOMedia Video 1）は、インターネット上での動画配信を目的として非営利団体のAlliance for Open Mediaが開発したオープンかつロイヤリティフリーな動画圧縮コーデックである" スマフォ、タブレット向けSoC 噂を含めてApple以外の主要なスマフォ向けSoCはAV1のハードウェアデコードをサポートする方向。 MediaTek のスマフォ向けSoC でAV1のハードウェアデコードをサポート Samsung のスマフォ向けSoCでAV1のハードウェアデコードをサポート Samsung Ex
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zigのサンプルプログラムをビルドするのに便利なMakefile
自動マウントするUSB外付けSSDにdockerのファイルを移動させる
