タグ

Cとgccに関するMonMonMonのブックマーク (10)

  • 次期C標準 (C23) の内容が固まったらしい

    C23については最近のC言語と、次期C標準(C23)でも軽く紹介しました。 今回、C23入りする内容が大体固まったようなので改めて紹介します。 この記事を書いている時点での最新の公開されたWorking Draftは N2912 N3047 N3054 N3096です。ただし、C2y向けの最初のドラフトN3220もあり、そちらの方が実際の内容に近いかもしれません。 内容については会議参加者の投稿も参考にしています: https://twitter.com/rcs/status/1550526425211584512 C23 now finalized! : C_Programming というわけで、C23に入る主な機能はこちらです: C23に入る主な機能 POSIXの機能の取り込み: strdup, strndup, memccpy, gmtime_r, localtime_r C++の機

    次期C標準 (C23) の内容が固まったらしい
  • コンパイラが作ったバイナリをつなぎ合わせるプログラム 「lld」の作者が語る、リンカの仕組み

    Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。植山氏は、制作中のリンカである「mold」について発表しました。全2回。前半は、リンカの概要について話しました。 LLVMのリンカ「lld」オリジナルの作者 植山類氏:植山類です。今僕が作っているmoldというリンカについて発表します。 今回の発表の概要です。リンカが何かを知っている人はそんなにたくさんいないと思うので、まず説明します。次に、「mold」のポイントは速いことなのですが、速いと何がうれしいのかを説明します。そのあと、どれくらい速いのかを説明した上で、どう実現されているのか、概要を紹介します。詳細になると何時間あっても終わらないので、かなりハイレベルな話をします。 自己紹介のスライドを入れていませんが、僕はリンカを何度か作ったことがあって、LLVMのlld

    コンパイラが作ったバイナリをつなぎ合わせるプログラム 「lld」の作者が語る、リンカの仕組み
  • bpftraceを使ってバイナリの謎の性能劣化を突き止めろ - Cybozu Inside Out | サイボウズエンジニアのブログ

    サイボウズ社内ではC++で開発している製品があります。 未知のバッファオーバーランなどの脆弱性への対策として、重要なコンポーネントについてはプロダクション環境で利用しているバイナリでも AddressSanitizer を有効にしてビルドしています。 その製品で利用しているコンパイラをgcc5.3.0からgcc7.5.0に更新したところ性能劣化が発生しました。 製品コードとは別の部分が原因のため、根原因の追跡が難しそうです。perf,bpftraceを使って性能劣化を追いかけてみましょう。 記事で利用しているAddressSanitizer, bpftrace, perfコマンドはネット上に良質な記事がありますので、使い方などの解説は今回は省略させていただきます。 gcc7.5.0において、性能劣化が発生する再現コードとして次のようなものを用意しました。 #include <strin

    bpftraceを使ってバイナリの謎の性能劣化を突き止めろ - Cybozu Inside Out | サイボウズエンジニアのブログ
  • セルフホスト可能なCコンパイラを書く

    最近、コンパイラを書くことが流行っているようだ。流行に乗ってやってみたらいろいろな知見が得られたので紹介したい。 コンパイラを書くと一口に言ってもいろいろなスコープがある。ここではC言語を用いてCコンパイラを書くことを選択した。C言語は言語仕様的にコンパクトで広く知られている。また、ツールとしてのCコンパイラも普及している。その場合、自分が書いたCコンパイラで、自分が書いたCコンパイラのソースコードをコンパイルすることが原理的には可能だ。これをセルフホストという。ひとつの到達目標として非常に興味深い。 当初は冬の間に終わらせる予定だったのだが春まで伸びてしまった。しかし、春になっても寒かったり雨で家に居る日が多く、アウトドアシーズンまでに目標のセルフホストを達成することができた。 昔、Cのインタプリタを書いたことがあったが、コンパイラを書くのは、はじめてである。時代も進んで開発手法が変わっ

  • Charming Python: Functional programming in Python, Part 3

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Charming Python: Functional programming in Python, Part 3
  • clang/gccに組み込まれたAddressSanitizer/LeakSanitizerでメモリエラーを捕捉する - 千里霧中

    C/C++でのユニットテストによるメモリリーク検出 - 千里霧中の補足。 メモリエラーの検出方法についてだけれど、最近のclangやgccだと、AddressSanitizerという動的解析ツールが組み込まれており、それを活用できる。 使用する場合はコンパイラオプション「-fsanitize=address」「-fsanitize=leak」等を指定する。 題材 例えば以下のコードを対象にする。 //main.c #include <stdio.h> #include <stdlib.h> void hoge(void) { int *a_buff = (int *)malloc(5 * sizeof(int)); a_buff[10] = 8; } int main(void) { printf("test\n"); hoge(); return 0; } これを普通にコンパイルして実行

    clang/gccに組み込まれたAddressSanitizer/LeakSanitizerでメモリエラーを捕捉する - 千里霧中
    MonMonMon
    MonMonMon 2016/02/03
    メモリリーク、メモリ破壊の検出ツール
  • gccで Wall & Wextra を使っても有効にならない警告 - Qiita

    gccで-Wall -Wextraを付けてもなお有効化されない警告オプションがあるそうなので、ドキュメントを読んでその効能を簡単に調べた。 なお、これらのオプションの中にはfortran、Objective-C用のものもあるようだが、それらについては説明を省く。 検証環境: gcc (Rev3, Built by MSYS2 project) 5.2.0 (やや特異な環境なのでLinuxなどの一般的な環境とは状況が違うかもしれない) 参考: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/Objective-C-and-Ob

    gccで Wall & Wextra を使っても有効にならない警告 - Qiita
  • GCCのコンパイルオプションで関数トレーサ - torutkのブログ

    このの「#77 関数へのenter/exitをフックする」で、GCCのコンパイルオプション-finstrument-functionsを使い、関数が呼び出された時、関数から復帰するときにフックを入れる方法が紹介されています。フック関数のシグニチャは以下です。 void __cyg_profile_func_enter(void* func_addr, void* call_site); void __cyg_profile_func_exit(void* func_addr, void* call_site); このフック処理に渡されるアドレスから関数名を出して、関数の実行を追う簡易な関数トレーサを作成します。アドレスから関数に変換する方法で一番簡単そうなのは、同じの「#62 dlopenで実行時に動的リンクする」でglibcのGNU拡張として紹介されているdladdr関数です。 #i

  • IPA ISEC セキュア・プログラミング講座:C/C++言語編 第10章 著名な脆弱性対策:バッファオーバーフロー: #4 あふれを検出するデバッグ

    第10章 著名な脆弱性対策 バッファオーバーフロー: #4 あふれを検出するデバッグ 領域あふれの問題の検出については、ロジックが複雑に入り組んでいる場合、ソースコードから見いだすのは容易でない。そのような場合、デバッガ等のツールの下で対象のプログラムを動かして、問題を見つけ出すことになる。 スタックおよびヒープにおけるあふれを検出するためのコンパイラのオプションやデバッグ・ツールがいくつか存在する。 次にその主なものを紹介する。 あふれの検出等に使うことのできるデバッグ・ツール ヒープにおける領域あふれやダブルフリー等の問題を検出できるツールをふたつ紹介する。ひとつは独立したツール、もうひとつは統合開発環境の中の機能である。 (1) Valgrind [GNU/Linux] ヒープデバッガを中心とした GNU/Linux 専用のツールスイートである。割当領域外への書き込みや、メモリリーク

  • GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ

    RubyPythonなどのスクリプト言語では実行中に例外が発生するとバックトレースを出力してくれます。バックトレースがあるとどこで問題が発生したかがわかるためデバッグに便利です。一方、CやC++では不正なメモリアクセスをすると、バックトレースではなくcoreを残して1終了します2。デバッガーでcoreを解析するとバックトレースを確認できます。 このように、CやC++でデバッグするときにデバッガーはなくてはならない存在です。スクリプト言語にもデバッガーはありますが、デバッガーを使わなくてもデバッグできる範囲が広いため、CやC++をデバッグするときのほうがデバッガーのありがたさがわかります。 この記事では、広く使われているデバッガーであるGDBをもっと便利に使うためのGCCのコンパイルオプション-g3を紹介します。 サンプルプログラム まず、この記事で使うサンプルプログラムを示します。マクロ

    GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ
  • 1