コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2021年1月24日 >>> 2021年1月11日
link もっと後

2021年1月22日

苦境のANA

年末(2020年12月20日の日記参照)に、1月はSUPER VALUE 21 Jより安いチケットがVALUE 3で出ると予想しましたが、外れましたね。1/30の羽田→札幌便を見ると、最安はVALUE 3 Jで年末からほとんど変わっていません。

いやまあ、SUPER VALUE 21とVALUE 3の値段がほとんど変わらない時点で、かなり異常事態なんですけど……。


1/30の羽田→札幌便

なんと全25便中、半分近い11便が欠航しています。飛ばす回数を自体を減らし、客単価の維持とおそらく各便ごとの黒字を確保しているのでしょう。単発で黒字が出たとしても、確実に収益にはダメージがありますよね。安いイメージが付いてしまうより良いのかなあ?

燃料費などは減便で節約できても、飛行機はリースなので飛んでも飛ばなくてもお金が掛かります。飛ばせるならいくらでも飛ばしたいでしょう。

早いところCOVID-19には収束してもらって、気軽に旅行や帰省できる日が来てほしいですね。ANAは今かなり苦しいでしょうけど、日本の翼を担う会社として何とか踏みとどまってほしいところ……。

編集者:すずき(2021/01/23 15:09)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年1月18日

Debian TestingとZephyr SDKその3 - パッチを当ててSDKビルド

目次: Zephyr

前回はツールチェーンビルドの仕組みを確認するためCrosstool-NGに立ち返り、正常動作するバイナリが作成できましたが、手順が多くて面倒でした。実はZephyr SDKだけでパッチを当てる仕組みがあります。

ローカルパッチディレクトリ

Crosstool-NGのパッチ当ては前回紹介したpackagesの下にあるパッチを使うのが基本ですが、他の場所(ローカルパッチディレクトリ)も追加できます。CT_LOCAL_PATCH_DIRというコンフィグに設定されます。

Crosstool-NGのローカルパッチディレクトリ設定
$ ./ct-ng menuconfig

Paths and misc options  --->
  () Local patch directory

Crosstool-NGのパッチ当て処理を見るとパッチを当てる順番を選択できるようになっています。

Crosstool-NGのパッチ当て実装

# crosstool-ng/scripts/functions

CT_DoExtractPatch()
{

...
            CT_DoLog EXTRA "Patching ${basename}"
            CT_DoExecLog ALL touch "${src_dir}/.${basename}.patching"

            bundled_patch_dir="${CT_LIB_DIR}/packages/${pkg_dir}"
            bundled_common_patch_dir="${CT_LIB_DIR}/packages/${pkg_name}"
            local_patch_dir="${CT_LOCAL_PATCH_DIR}/${pkg_dir}"    #★★ローカルパッチディレクトリ

            #★ディレクトリ名を列挙
            #★patch_orderは "bundled, local" になっていた、CT_PATCH_ORDERで決まるようだ
            case "${patch_order}" in
                bundled)        patch_dirs=("${bundled_patch_dir}" "${bundled_common_patch_dir}");;
                local)          patch_dirs=("${local_patch_dir}");;
                bundled,local)  patch_dirs=("${bundled_patch_dir}" "${bundled_common_patch_dir}" "${local_patch_dir}");;
                local,bundled)  patch_dirs=("${local_patch_dir}" "${bundled_patch_dir}" "${bundled_common_patch_dir}");;
                none)           patch_dirs=;;
            esac

            CT_Pushd "${src_dir}/${basename}"
            for d in "${patch_dirs[@]}"; do    #★ディレクトリを順に辿る
                CT_DoLog DEBUG "Looking for patches in '${d}'..."
                if [ -n "${d}" -a -d "${d}" ]; then
                    for p in "${d}"/*.patch; do
                        if [ -f "${p}" ]; then
                            CT_DoExecLog ALL ${patch} --no-backup-if-mismatch -g0 -F1 -p1 -f -i "${p}"
                        fi
                    done
                fi
            done

...

今回のケースではpatch_orderは "bundled, local" になっていたので、packages -> ローカルパッチの順にパッチを当てるようです。patch_orderの決め方は深追いしていませんが、CT_PATCH_ORDERで決まるようです。

Zephyr SDKにパッチを追加

Zephyr SDKの設定ファイルを見るとローカルパッチディレクトリは下記のようになっています。

Zephyr SDKのローカルパッチディレクトリ設定内容
# configs/riscv64.config

...

CT_LOCAL_PATCH_DIR="${CT_TOP_DIR}/../../patches"

CT_TOP_DIRとは何でしょう?ビルドログを追うとCT_TOP_DIR=/.../sdk-ng/build/build_riscv64でした。すなわちsdk-ng/patchesがローカルパッチディレクトリです。ディレクトリには既に6つほどのパッチが置かれています。

Zephyr SDKのローカルパッチディレクトリ(GDB用)
$ ls patches/gdb/9.2

0001-gdb-remote-make-tid-pid-type-long-in-write_ptid.patch
0002-gdb-Add-fixes-for-stdint-and-remote-debug-on-xtensa.patch
0003-gdb-xtensa-don-t-error-out-when-registers-cannot-be-.patch
0004-gdb-xtensa-use-remote-target-register-numer.patch
0005-gdb-arch-to-tell-whether-it-supports-g-packets.patch
0006-gdb-xtensa-support-disabling-use-of-g-packet.patch

ここにPython 3.9で落ちる問題を修正するパッチを追加します。

Zephyr SDKにGDBのパッチを追加する
$ cd sdk-ng

$ cat > patches/gdb/9.2/0007-gdb-fix-python3.9.patch
(パッチをコピペする)

$ ./go.sh riscv64

ビルドログはbuild/build_riscv64/build.logに作られます。

Zephyr SDKのパッチ当てログを確認
# Crosstool-NGの持っているパッチを当てているログ

[DEBUG]    Looking for patches in 'sdk-ng/share/crosstool-ng/packages/gdb/9.2'...
[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'sdk-ng/share/crosstool-ng/packages/gdb/9.2/0000-musl_fix.patch'
[ALL  ]    patching file gdb/linux-nat.c
[ALL  ]    patching file gdb/stopcode.h
[DEBUG]    ==> Return status 0

...


# Zephyr SDKのローカルパッチを当てているログ

[DEBUG]    Looking for patches in 'sdk-ng/share/crosstool-ng/packages/gdb'...
[DEBUG]    Looking for patches in 'sdk-ng/build/build_riscv64/../../patches/gdb/9.2'...
[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'sdk-ng/build/build_riscv64/../../patches/gdb/9.2/0001-gdb-remote-make-tid-pid-type-long-in-write_ptid.patch'
[ALL  ]    patching file gdb/remote.c
[DEBUG]    ==> Return status 0

...


# 追加したパッチを当てているログ

[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'sdk-ng/build/build_riscv64/../../patches/gdb/9.2/0007-gdb-fix-python3.9.patch'
[ALL  ]    patching file gdb/python/python.c
[ALL  ]    Hunk #1 succeeded at 234 (offset -4 lines).
[ALL  ]    Hunk #2 succeeded at 271 (offset -4 lines).
[ALL  ]    Hunk #3 succeeded at 952 (offset -19 lines).
[ALL  ]    Hunk #4 succeeded at 1552 (offset -68 lines).
[ALL  ]    Hunk #5 succeeded at 1720 (offset -70 lines).
[ALL  ]    patch unexpectedly ends in middle of line
[DEBUG]    ==> Return status 0

ちなみにZephyr SDKのビルド後、GDBのソースコードはsdk-ng/build/build_riscv64/.build/riscv64-zephyr-elf/src/gdbに展開されます。パッチが正常に当たったか確認するなら、このソースコードを見れば確実でしょう。

SDKはbuild/output以下に生成されます。RISC-V 64であればbuild/output/riscv64-zephyr-elfです。生成されたバイナリが動くか確かめましょう。

生成されたGDBを実行
$ cd build/output/riscv64-zephyr-elf/bin

$ ./riscv64-zephyr-elf-gdb --version
GNU gdb (crosstool-NG 1.24.0.212_d7da3a9) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

動きました、良かった良かった。build/output下に生成されたriscv64-zephyr-elfディレクトリをZephyr SDKのインストールディレクトリ下にある同名のディレクトリと差し替えれば、GDBが動くはずです。

編集者:すずき(2023/09/24 12:02)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年1月17日

Debian TestingとZephyr SDKその2 - パッチを当ててSDKビルドをする前に

目次: Zephyr

GDBとPython 3.9の組み合わせは、SEGVでクラッシュしました。調べてみると FedoraのBugzilla にドンピシャの情報が載っていました。Python 3.9とGDBの組み合わせが動かなかったこと、Red Hatの人がパッチを作ってくれて、5/28に修正されたこと、などが書いてあります。

Zephyr SDKのGDBは9.2(2020年5月23日リリース)で、上記のPython 3.9で動かすための修正は入っていません。残念。選択肢としては下記の2つが考えられます。

  • 10.1(2020年10月24日リリース)を使う
  • 9.2 + クラッシュを治すパッチ(リンク)を当てる

GDBのバージョンを変えると新たな厄災を招く恐れがあるため、今回は保守的に9.2 + パッチで行こうと思います。

基本(Crosstool-NG)に立ち戻る

Zephyr SDKは内部でCrosstool-NGというツールチェーンのビルドツールを利用しています。Zephyr SDKに突撃する前にCrosstool-NGの仕組みをおさらいし、9.2 + パッチでビルドする方法を試します。

Zephyr SDKのconfigs/ ディレクトリの下を見ると *.configファイルがたくさんあります。実はこれらはCrosstool-NGのコンフィグファイルです。このファイルをCrosstool-NGにコピーするとツールチェーンが作成できます。わかりやすいですね。

Zephyr SDKが持っているCrosstool-NGのコンフィグファイル
$ cd sdk-ng

$ ls configs/
arc.config    nios2.config                  xtensa_intel_byt_adsp.config
arm.config    riscv64.config                xtensa_intel_s1000.config
arm64.config  sparc.config                  xtensa_nxp_imx8m_adsp.config
i586.config   x86_64-zephyr-elf.config      xtensa_nxp_imx_adsp.config
iamcu.config  xtensa_intel_apl_adsp.config  xtensa_sample_controller.config
mips.config   xtensa_intel_bdw_adsp.config

Crosstool-NGはツールチェーンの各モジュールにパッチを当てられます。例えばGDB 9.2ならばpackages/gdb/9.2/ の下にパッチファイルを置くと、若い番号から順番にパッチ適用してくれます。

Crosstool-NGのGDB 9.2用パッチ
$ ls packages/gdb/9.2/

0000-musl_fix.patch                                 0004-allow-android.patch
0001-uclibc-no-gettimeofday-clobber.patch           chksum
0002-xtensa-make-sure-ar_base-is-initialized.patch  version.desc
0003-WIP-end-of-prologue-detection-hack.patch

このディレクトリに0005-xxxx.patchのような名前のパッチを追加すると、0004-allow-android.patchのあとにパッチを当ててくれます。便利ですね。パッチ当て処理の実装を見ましょう。

Crosstool-NGのパッチ当て実装

# crosstool-ng/scripts/functions

CT_DoExtractPatch()
{

...

            CT_Pushd "${src_dir}/${basename}"
            for d in "${patch_dirs[@]}"; do
                CT_DoLog DEBUG "Looking for patches in '${d}'..."
                if [ -n "${d}" -a -d "${d}" ]; then
                    for p in "${d}"/*.patch; do    #★パッチファイルを列挙、パッチ当てる
                        if [ -f "${p}" ]; then
                            CT_DoExecLog ALL ${patch} --no-backup-if-mismatch -g0 -F1 -p1 -f -i "${p}"
                        fi
                    done
                fi
            done

...

ビルド後にできるログbuild.logをLooking for patchesで検索していくと、パッチを当てている箇所が確認できます。

Crosstool-NGのパッチ当てログ
...

[DEBUG]    Looking for patches in 'crosstool-ng/packages/gdb/9.2'...
[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'crosstool-ng/packages/gdb/9.2/0000-musl_fix.patch'
[ALL  ]    patching file gdb/linux-nat.c
[ALL  ]    patching file gdb/stopcode.h
[DEBUG]    ==> Return status 0
[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'crosstool-ng/packages/gdb/9.2/0001-uclibc-no-gettimeofday-clobber.patch'
[ALL  ]    patching file gnulib/configure
[ALL  ]    patching file gnulib/import/m4/gettimeofday.m4
[DEBUG]    ==> Return status 0

...

Crosstool-NGがパッチを当てる順はシェルのファイル列挙順のため、ファイル名は必ずしも数字で始める必要はないです。しかし、前例に習ったほうが良いでしょう。パッチを0005-fix-python3.9.patchという名前で追加します。

Crosstool-NGでパッチを追加してビルド
$ git clone https://github.com/crosstool-ng/crosstool-ng
$ cd crosstool-ng

$ cat > packages/gdb/9.2/0005-fix-python3.9.patch
(パッチをコピペする)

$ ./bootstrap
$ ./configure --enable-local
$ make

$ cp ../sdk-ng/configs/riscv64.config ./.config

$ ./ct-ng menuconfig
$ ./ct-ng build

ビルド後にできるログbuild.logを確認して、パッチが当たっていることを確かめます。

Crosstool-NGのパッチ追加後のログ
...

[DEBUG]    Looking for patches in 'crosstool-ng/packages/gdb/9.2'...
[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'crosstool-ng/packages/gdb/9.2/0000-musl_fix.patch'
[ALL  ]    patching file gdb/linux-nat.c
[ALL  ]    patching file gdb/stopcode.h
[DEBUG]    ==> Return status 0
[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'crosstool-ng/packages/gdb/9.2/0001-uclibc-no-gettimeofday-clobber.patch'
[ALL  ]    patching file gnulib/configure
[ALL  ]    patching file gnulib/import/m4/gettimeofday.m4
[DEBUG]    ==> Return status 0

...

[DEBUG]    ==> Executing:  '/usr/bin/patch' '--no-backup-if-mismatch' '-g0' '-F1' '-p1' '-f' '-i' 'crosstool-ng/packages/gdb/9.2/0005-python3.9.patch'
[ALL  ]    patching file gdb/python/python.c
[ALL  ]    Hunk #1 succeeded at 234 (offset -4 lines).
[ALL  ]    Hunk #2 succeeded at 271 (offset -4 lines).
[ALL  ]    Hunk #3 succeeded at 952 (offset -19 lines).
[ALL  ]    Hunk #4 succeeded at 1552 (offset -68 lines).
[ALL  ]    Hunk #5 succeeded at 1720 (offset -70 lines).
[ALL  ]    patch unexpectedly ends in middle of line
[DEBUG]    ==> Return status 0

GDBの開発メールアーカイブから適当にコピペしてパッチを作ったので、Hunkがずれてるよって怒られましたが、パッチ当ては成功しています。あまり気にしなくても良いでしょう。ビルド後は動作確認しましょう。

Crosstool-NGでパッチ追加後のバイナリ動作確認
$ cd ~/x-tools/riscv64-zephyr-elf/bin

$ ./riscv64-zephyr-elf-gdb --version

GNU gdb (crosstool-NG 1.24.0.254_fcf3233) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

動きました。良かった良かった。

編集者:すずき(2023/09/24 12:01)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年1月16日

RISC-V QEMUのデバッグ用ビルド方法

目次: RISC-V

たまにRISC-V向けのQEMUの動きを見たいときがあって、デバッグビルドをするのですが、やり方を忘れがちなのでメモしておきます。

QEMUビルド

$ mkdir build
$ cd build

$ ../configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-softmmu,riscv64-linux-user \
    --disable-docs --enable-debug

...

qemu 5.2.50

                   Install prefix: /usr/local
                   BIOS directory: share/qemu
                    firmware path: /usr/local/share/qemu-firmware
                 binary directory: bin
                library directory: lib
                 module directory: lib/qemu
                libexec directory: libexec
                include directory: include
                 config directory: /usr/local/etc
            local state directory: /usr/local/var
                 Manual directory: share/man
                    Doc directory: /usr/local/share/doc

...

                 thread sanitizer: NO
                         rng-none: NO
                    Linux keyring: YES
                     FUSE exports: NO
                       FUSE lseek: NO

  Subprojects
                    libvhost-user: YES

Found ninja-1.10.1 at /usr/bin/ninja

$ ninja

ビルドが成功するとbuildディレクトリ以下にqemu-system-riscv32やqemu-system-riscv64が生成されているはずです。

編集者:すずき(2021/07/15 20:35)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年1月14日

Debian TestingとZephyr SDKその1 - 自分でSDKをビルド

目次: Zephyr

開発用のマシンではDebian Testingを使っているのですが、久しぶりにdist-upgradeしたところPython 3.8が消えてしまいました。Python 3.9に移行したみたいです。

アップデート時は「そうなんだ、3.9になったんだな。」くらいの認識でスルーしまいたが、Zephyrを使おうとしたら異変に気づきました。なんとZephyr SDKのGDBが動きません。どうしてこうなった。

GDBを起動するとエラー
$ riscv64-zephyr-elf-gdb
riscv64-zephyr-elf-gdb: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

Debianは元々Zephyr SDKのサポート範囲に入っていない(Ubuntuのみ)ですし、Debian Testingなんてサポートされるはずがないので、自力で解決する必要があります。

Zephyr SDKのビルド

Zephyr SDKのビルド手順は簡単ですが、Debian Testingだとうまくいきません。

Zephyr SDKのビルド
$ git clone https://github.com/zephyrproject-rtos/sdk-ng
$ cd sdk-ng

$ ./go.sh riscv64
./go.sh: 行17: python: コマンドが見つかりません

Pythonが見つからず怒られます。Debian Testingは /usr/bin/pythonがなくなったため、go.shのpythonをpython3に書き換えてあげると動きます。他にもPython 3.8を想定している箇所があるので、Python 3.9に直します。

Zephyr SDK改変(RISC-V 64向け)

diff --git a/configs/riscv64.config b/configs/riscv64.config
index 295f2c0..a9fc301 100644
--- a/configs/riscv64.config
+++ b/configs/riscv64.config
@@ -46,5 +46,5 @@ CT_CC_LANG_CXX=y
 CT_CC_GCC_LIBSTDCXX_NANO=y
 CT_DEBUG_GDB=y
 CT_GDB_V_9_2=y
-CT_GDB_CROSS_PYTHON_BINARY="python3.8"
+CT_GDB_CROSS_PYTHON_BINARY="python3.9"
 CT_GDB_CROSS_BUILD_NO_PYTHON=y
diff --git a/go.sh b/go.sh
index e5442fa..7a45fd8 100755
--- a/go.sh
+++ b/go.sh
@@ -14,7 +14,7 @@ fi
 
 COMMIT="d7da3a9c7f0f3a90bb4c71b91aea6cbc2471a541"
 GITDIR=${PWD}
-JOBS=$(python -c 'import multiprocessing as mp; print(mp.cpu_count())')
+JOBS=$(python3 -c 'import multiprocessing as mp; print(mp.cpu_count())')
 
 unameOut="$(uname -s)"
 unameMachine="$(uname -m)"

SDKはbuild/output以下に生成されます。RISC-V 64であればbuild/output/riscv64-zephyr-elfです。生成されたバイナリが動くか確かめましょう。

生成されたGDBを実行
$ cd build/output/riscv64-zephyr-elf/bin

$ ./riscv64-zephyr-elf-gdb
Segmentation fault

SEGVで死にました。うーん、だめそうですね……。次回以降、直せないかトライします。

編集者:すずき(2023/09/24 12:01)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2021年1月24日 >>> 2021年1月11日
link もっと後

管理用メニュー

link 記事を新規作成

<2021>
<<<01>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事20件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
  • link 24年3月3日
    すずき (03/19 11:07)
    「[解像度の設定を保存する] 目次: LinuxRaspberry Pi 3 Model B (以降RasPi 3B)のHDMI...」
  • link 24年3月14日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信] 目次: ArduinoM...」
  • link 24年3月8日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - BluetoothデバイスとServiceの列挙] 目次: A...」
  • link 23年6月2日
    すずき (03/16 21:11)
    「[Arduino - まとめリンク] 目次: Arduino一覧が欲しくなったので作りました。 M5Stackとesp32とA...」
  • link 23年5月15日
    すずき (03/16 00:57)
    「[車 - まとめリンク] 目次: 車三菱FTOの話。群馬県へのドライブ将来車を買い替えるとしたら?FTOのオイル交換とオイル漏...」
  • link 24年3月9日
    すずき (03/16 00:56)
    「[車のバッテリー完全に死亡で交換かと思いきや] 目次: 車またまた車のバッテリーが干上がって死にました。写真は撮っていませんが...」
  • link 24年3月10日
    すずき (03/15 03:34)
    「[誕生日] 早いもので41歳になりました。昨年の日記(2023年3月10日の日記参照)を見ると、コロナの流行を心配していました...」
  • link 24年3月6日
    すずき (03/12 01:18)
    「[Raspberry Pi 3 model Bの代わりにROCK 3 model C] 目次: Arduino最近、M5Sta...」
  • link 24年3月4日
    すずき (03/06 00:09)
    「[volatileをnon-volatileで参照してはいけない] 目次: GCC過去の日記(2021年3月13日の日記参照)...」
  • link 20年6月2日
    すずき (03/06 00:06)
    「[GCC - まとめリンク] 目次: GCCGCCについて。GCCを調べる - その1 - ビルドGCCを調べる - その2 ...」
  • link 15年5月9日
    すずき (03/05 03:00)
    「[自作ARMエミュレータ - 今さら気づいたブートローダのバグ] 目次: Linuxずっと気づいていなかった自作ARMエミュレ...」
  • link 23年6月1日
    すずき (03/05 02:59)
    「[自宅サーバー - まとめリンク] 目次: 自宅サーバーこの日記システム、Wikiの話。カウンターをPerlからPHPに移植日...」
  • link 15年5月3日
    すずき (03/05 02:59)
    「[GRUB2が起動しなくなってしまった] 目次: 自宅サーバーサーバにインストールしていたDebian 32bit版 のJes...」
  • link 15年5月2日
    すずき (03/05 02:58)
    「[systemdを使うのをあきらめた] 目次: 自宅サーバー独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われ...」
  • link 15年4月30日
    すずき (03/05 02:56)
    「[Debian 8.0 Jessie] 目次: 自宅サーバーDebianのアップデートが来ていたので、試しに職場のPCをアップ...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20