論文｜MESH: Compacting Memory Management for C/C++ Applications (PLDI 2019)
「MESH: Compacting Memory Management for C/C++ Applications」という論文を読んだのでその紹介です。arXiv.org で公開されています。PLDI 2019 で採択されている論文のドラフトだそうです。私は v2 を読みました。ソースコードが GitHub (plasma-umass/Mesh) で公開されています。 免責 読み間違えている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue や Twitter へお願いします。 読んだ動機 C/C++ でリロケーションせずにコンパクションを行う手法に興味があった。 Speedmetor 2.0 benchmark を走らせた Firefox でメモリ消費量が減ったと報告されており、ブラウザ開発者として気になった。 Ch
gdbでアドレスが指す先のアドレスをdereferenceするコマンドを作った - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
gdbであるアドレスがアドレスを指している場合のdereferenceを簡単にやりたかったのでpythonでコマンド作ってみました。 これは例えばcのコードがこうで、 void func(char *p) { printf("[*] %s\n", p); } func()のディスアセンブル結果にこのような処理があるとします。 0x000000000040066e <+8>: mov %rdi,-0x8(%rbp) このとき、rbp - 8のアドレスは0x7fffffffdc68で、ここはアドレス0x0000000000602010を指しています。 (gdb) x/gx $rbp - 8 0x7fffffffdc68: 0x0000000000602010 このアドレスが指す内容は以下のようにしてdereferenceできますが、ちょっと面倒ですよね。 (gdb) x/s *(char **
静的解析に引っかからなかったメモリ破壊の話 - Qiita
リセットされるカウンタは g_loop_counter です。 いったい何がいけないのか、わかりますか？ mapファイルで確認すると、g_loop_counter は g_is_error_flg の次のアドレスでした。 ステップ実行して g_is_error_flg = false; で g_loop_counter に 0 が書き込まれるのを確認できました。 ただ、g_is_error_flg = false; の何がいけないのか、しばらくは分かりませんでした。 mogemoge.c から見ると、g_is_error_flg の宣言はどっか別の所にあって、mogemoge.c 内では unsigned int として扱うしかない訳です。 ところが、アドレスの割り付けとしてはg_is_error_flg と g_loop_counter で１バイトずつでしか割り当てられていない訳で。 困
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
