GCC開発者らがGoogleの「Go」をサポートする方針を発表
Googleが昨年発表したオープンソースのプログラミング言語「Go」が早ければGCC 4.5でマージされることが明らかになった。 GNU Compiler Collection（GCC）を監督するGCC Steering Committeeは1月26日、米Googleの「Go」をサポートする方針を発表した。早ければ「GCC 4.5」でマージされるという。 Goは、Googleが2009年11月に発表したオープンソースのプログラミング言語。Pythonのような動的言語の開発スピードと、CやC++のようなコンパイル言語の性能を併せ持つことを目的とする。 GCCは今後、gccgoフロントエンドとgccランタイムの貢献を受け付けマージを進める。メンテナーはGoogleのイアン・タイラー氏。サポートはGCC 4.5以降となり、GCCリリースマネジャーがコンパイラにマージする時期などを決定する。 GC
gccの-fstack-protectorとか - SYNjuku-ACKihabara
http://vrt-sourcefire.blogspot.com/2009/07/how-do-i-become-ninja.htmlを読んで http://community.corest.com/~gera/InsecureProgramming/をやってみた WARMING UP on STACKではこんな感じの明らかに脆弱なプログラムが問題になっている /* stack1.c * * specially crafted to feed your brain by gera */ int main() { int cookie; char buf[80]; printf("buf: %08x cookie: %08x\n", &buf, &cookie); gets(buf); if (cookie == 0x41424344) printf("you win!\n"); } W
スタックプロテクターは alloca 割り当てを使うプログラムも守ってくれるか？ - IKB: 雑記帳
先だって同僚からそんな疑問を受け、気になっていたので調べた。結論から言うと、守ってくれる。 そもそもスタックプロテクターは、関数呼び出し時にスタックフレーム内の戻りアドレスの直上にカナリア変数を置き、呼び出し元に返る前にカナリア変数がオーバーフローによって破壊されていないことを確かめるという実装だから（つまりカナリア変数が壊れていたら戻りアドレスも壊されているだろうから、そこへ ret してはいけないと判断する）、スタックが可変長だろうと関係なく守ってくれるっていうわけ。 というわけでサンプルコード。 /* stack-protector.c */ #include <stdlib.h> /* for alloca */ #include <memory.h> /* for memset */ void f() { memset(alloca(1), 0x90, 56); } int ma
IPA ISEC セキュア・プログラミング講座：C/C++言語編 第10章 著名な脆弱性対策：バッファオーバーフロー: #5 運用環境における防御
第10章 著名な脆弱性対策 バッファオーバーフロー: #5 運用環境における防御 近年、オペレーティングシステムには、バッファオーバーフロー等の攻撃を失敗に終わらせるためのいくつかの防御機能が備わりつつある。それは、主に次の3つである スタック保護 関数リターンアドレス書き変えを検出し、それ以上の実行を止める メモリ空間レイアウトのランダマイズ メモリ上の特定の位置を狙ってのアドレスワードの不正書き変えや、侵害コードへのジャンプといった操作を失敗させる データ実行防止 万一侵害コードへのジャンプが行われたとしてもデータ領域に置かれた機械語コードを実行させない スタック保護 近年Cコンパイラも進歩し、関数をコンパイルして生成される機械語コードの中に、領域あふれによってスタック上の関数リターンアドレスが改変されていることを検知する機械語コードを挿入できるものが登場している。 その主なものが、G
yunoの雑記帳 - gcc/warning
gcc4.1の、-Wallで有効にならない警告オプションのメモ。 概要だけなので、適宜マニュアルを参照した方がいいです。 -Wformat-y2k strftimeで2桁の年を出力する書式を警告する。 -Wformat-nonliteral 引数にva_listを取る書式化関数を除き、書式文字列が文字列リテラルでないためチェックできない場合に警告する。 -Wformat-security セキュリティ上の問題の可能性がある書式化関数の使用法について警告する。 現在、printfとscanf関数で書式文字列が文字列リテラルでなく書式引数がない、例えば`printf(foo);'のような場合に警告する。 -Winit-self それ自身を使って初期化している未初期化変数について警告する。 例えば以下のようなコードを警告する。 int i = i; -Wmissing-include-dirs
gcc の -Wall 以外の警告オプション - ひげぽん OSとか作っちゃうかMona-
以前同僚の光成さんが、以下の warning オプションを使っていると書かれていたのが気になったので調べてみました。 -Wall -W -Wformat=2 -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wfloat-equal -Wpointer-arith もし上記以外にも良さげなオプションがありましたら教えてください<(_ _)> 情報源 man と info と http://sugarpot.sakura.ne.jp/yuno/?gcc%2Fwarning 。 最初は日本語版の man だけを見ていたのですが、id:kazuhooku に info を見るべしと教わりました。 man も info もそうですが、日本語版は情報が少なかったりするので注意。 LANG=C man gccなどとしましょう。 -Wforma
【レポート】FreeBSD GCCアップデート停止、LLVM Clangへ移行 - BSDCan 2010 | エンタープライズ | マイコミジャーナル
FreeBSD、GCC 4.2.1でアップデート停止 FreeBSD - The Power To Serve FreeBSDはシステムコンパイラとツールチェーンの入れ替えを進めている。2010年5月中旬にカナダで開催されたBSDCan2010およびFreeBSD Developer Summitで、このあたりのまとまった議論と発表があった。GCCからLLVMへの移行はFreeBSDのみならず他のOSSプロジェクトでも進んでいる。FreeBSDの事例が他のプロジェクトにすべて当てはまるわけではないが、FreeBSDの場合にはどういった背景があってLLVMへの移行が決定されたのかがわかって興味深い。なお、いくつかのプロジェクトはFreeBSDと似たような理由で移行を進めている。 FreeBSDはこれまでGCCをシステムのデフォルトコンパイラとして採用してきた。強力な機能、必要とするアーキテク
GCC開発者らがGoogleの「Go言語」をサポートする方針を発表 | OSDN Magazine
GNU Compiler Collection（GCC）を監督するGCC Steering Committeeは1月26日、米Googleの「Go」をサポートする方針を発表した。早ければ「GCC 4.5」でマージされるという。 Goは、Googleが2009年11月に発表したオープンソースのプログラミング言語。Pythonのような動的言語の開発スピードと、CやC++のようなコンパイル言語の性能を併せ持つことを目的とする。 GCCは今後、gccgoフロントエンドとgccランタイムの貢献を受け付けマージを進める。メンテナーはGoogleのIan Taylor氏。サポートはGCC 4.5以降となり、GCCリリースマネージャがコンパイラにマージする時期などを決定する。 GCCは現在、C、C++、Objective-C、Fortran、Java、Adaをサポートしており、最新版は1月21日リリースし
Doug Lea の malloc (dlmalloc) - bkブログ
Doug Lea の malloc (dlmalloc) 小さなオブジェクトを大量に new しまくるプログラムを C++ で書いたところ、処理時間の多くが malloc() に費やされていることがわかりました。このような場合、自前でメモリ管理を行って最適化するという方法がありますが、なかなか大変です。 そこで、安易に高速な malloc に置き換えてみようということで、 Doug Lea の malloc (通称 dlmalloc) の最新版を試してみました。 dlmalloc の使い方 dlmalloc は 1ファイルをダウンロードしてビルドすれば使えます。次のように実行すると共有ライブラリ libdlmalloc.so を作れます。現時点でのバージョンは 2.8.3 でした。 % wget ftp://g.oswego.edu/pub/misc/malloc.c % gcc -O2
Ubuntu 8.04 で gcc が動かない...? - trial and error
最近、とにかく Linux 業界では Ubuntu が流行りのような気がします。 僕は、あのディズトリビューション、あまり好きではないのですが、確かに最初に Linux に触れるにはよいディストリビューションかも。 だけど、なんか変なところもあるということが、今回の探りで明らかになった。 このきっかけは、キャンプで知り合った中学生 id:gin5005 氏の疑問である。 gcc は動くんだけど、何やら大量にエラーを吐かれる。 それも、stdio.h がないとか言われる。 さらに、printf なんじゃそりゃ？とか言われる。 これはもしや・・・。変な想像が頭をよぎる。 試してみた。 Ubuntu 8.04 をふつーにインストールして、適当なプログラム作って実行。 techno@ubuntu-vm:~$ cat test.c #include <stdio.h> int main(void)
moratorium | flock(2)はスレッドも排他するか？
flock(2)はスレッドも排他するか？ 以前人づてに、flock(2)がプロセス間排他はするけどスレッド間排他はしないという話を聞いた。 これが本当だと、今まで自分が書いたマルチスレッドアプリケーションのファイルを扱う部分の根幹が揺らいでしまう。特にファイルが壊れたりするような現象は見られなかったので今まで放置してきたが、非常に心配になってきたので調べてみた。 実験環境と検証用コードは以下の通り。 dylan% uname -a Linux dylan 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux dylan% gcc --version gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Copyright (C) 2006
GCC (libstdc++) 付属の STL をマルチスレッド環境で使うにはどういう設定が要るんでしょうか？という基本的な疑問 - Cry's Blog
あったあった． When you link a multithreaded application, you will probably need to add a library or flag to g++. This is a very non-standardized area of GCC across ports. Some ports support a special flag (the spelling isn't even standardized yet) to add all required macros to a compilation (if any such flags are required then you must provide the flag for all compilations not just linking) and link-lib
ビルド時間の短縮 - kryozahiro’s diary
Boostは便利だけど、ちょっと使っただけでビルド時間が一気に長くなってしまうので、何とかならないか調べてみた。 まず、最近のgccではプリコンパイル済みヘッダ（PCH）が使えるらしい。しかし、ヘッダをプリコンパイルしたときのオプションが本番のコンパイル時と違う場合、プリコンパイル済みヘッダは利用されない可能性が高いとのこと（http://d.hatena.ne.jp/rero/20080609/p1）。リリース時のみ使うか、VCで言うところのstdafx.hのようにプロジェクトごとのプリコンパイル済みヘッダを用意する、ということになりそう。 次に、以前から名前は知っていたccacheを見つけた。（本家、windows版） これはヘッダをプリプロセスした結果をキャッシュするツールで、使い方は単に $ ccache gcc foo.c とすれば二度目からコンパイルを高速化してくれる。 こっち
lucille 開発日記: gcc と sse と pthread と。
gcc と sse と pthread と。 さて、lucille を久しぶりに linux 上で gcc でコンパイルしてみたのですが、 sse と pthread を有効にして、マルチスレッドで SSE コードを実行すると、 スレッドで実行される関数内のローカル変数が 16 バイト境界にアラインされないので落ちる、 という結果になりました。 この現象は gcc でしか生じず(icc や vc では生じない)、 結構前から問題になっていました。 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11961 今回最新の gcc 3.4.1 で試してみたのですが、やっぱりなおっていませんでした。 バグジラだと resolved ってなっているのになぁ... 実際には、これは gcc コンパイラが原因によるものではなく、 pthread や glibc 周
localtimeやstrtokは本当にスレッドセーフにできないのか (3)： GCC __thread keyword - memologue
3.3以降のgccを使っているのであれば、pthread_getspecific関数を使うのと同様のことを、特殊なキーワード __thread を使って実現できます。上で示したlocaltime関数の、長ったらしいソースコードは、次のように簡潔に書き直せます。 #include <time.h> #include <stdlib.h> struct tm* localtime(const time_t* timep) { static __thread struct tm ret; return localtime_r(timep, &ret); }このコードを gcc -S -fverbose-asm してみると、pthread_key と pthread_once を使った上のソースコードより簡潔なコードが吐かれております。移植性を気にしないなら、可読性・速度ともにこちらの方法が勝って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
lcov
Infoseek[インフォシーク] - 楽天が運営するポータルサイト![Infoseek[インフォシーク] - 楽天が運営するポータルサイト](https://cdn-ak-scissors.b.st-hatena.com/image/square/67a82fbafb5e06f77d53cedfd9ceb7f789258213/height=288;version=1;width=512/https%3A%2F%2Fimage.infoseek.rakuten.co.jp%2Fcontent%2Ftop-ajax%2Fmobile%2Flogo.png)
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30.3
Nabble - gcc - bugs - [Bug bootstrap/40105] New: [4.3/4.4 Regression] SH: segfault when recompiling itself
http://gcc.gnu.org/viewcvs?view=rev&revision=147780