Solaris/x86のスタック領域がなぜ低位に確保されるのか？

藤原さんの「理解した気分になる Solaris Internals "Chapter 9: Virtual Memory" 総ざらえ」の疑問

x86 のスタック領域がアドレス低位に確保されるのは、 Solaris 固有の話？それとも他の OS でも共通の、CPU 固有の話？

の答え、ちょっと調べた感じだと、どうも歴史的なもののようです。
（質問の回答としては、Solaris固有ではないが、CPU固有といえば固有、他のOSでも共通かどうかは不明というところでしょうか。）

まず話を聞いていない人向けに書くと、Solaris/SPARC(32bit,64bit)やSolaris/x64はそんなことないのに、
Solaris/x86だけ、スタックが妙に低いアドレス(0x8048000)から伸びているけどなんぞ、というお話です。
cf. Solaris Internalsの図

このアドレスがキーなのかと思って検索してみたらどうもそうのようで、このアドレスは
ELFのエントリポイントの模様。

リンカとかローダの話ですかと思って手元の「Linkers & Loaders」を調べてみたら、まさにそれっぽい記述を見つけました。

ELFがa.outと異なるのは、オブジェクトを0番地付近ではなくアドレス空間の中程にロードして、スタックがテキストセグメントの下位から成長し、ヒープがデータセグメントの終端から成長するようにすることによって、全体として利用するアドレス空間が比較的小さく済むようにしている点である。386システムでは、テキストのベースアドレスは0x08048000で、テキストの前の0x08000000以降の部分に十分に大きなスタックを確保できると同時に、ほとんどのプログラムでは第2レベルのページテーブルは1つだけで済む（386においては、1つの第2レベルテーブルで0x00400000のアドレスをマップできる）。

決めた時代的には、ここに置くとアドレスがいい感じだったということのようですね。

なおこれを決めたのは「Re: is not 0x8048000 too wasteful?--about virtual address layout」によると、

There is folklore that 0x08048000 once was STACK_TOP (that is, the stack
grew downwards from near 0x08048000 towards 0) on a port of *NIX to i386
that was promulgated by a group from Santa Cruz, California. This was
when 128MB of RAM was expensive, and 4GB of RAM was unthinkable.

ということで、1983年のSCOでしょうか。

ちなみに、Linux/x86 (2.6)は上記場所にスタックはできないようです。


なお、もっと詳しい方がいればブログなりでフォローいただければ修正します :)

ちなみにこの「Linkers & Loaders」、ひさびさに読み始めてたのですが、本を見ると2001年初版。出た当初に買ったはず（だいぶ色あせてる）なので、10年後にまた読むとは。前知識なしで読むと全然わからない（10年前がそうだった）ですが、最近のx86やらOSやらの勉強でようやくわかるようになってきました。
Amazonの評価はよくないですが、これだけ一通り書いてあってもし読みやすい本があれば是非知りたい感じです。

GNOME ShellのFavorites Barに好きなプログラムを追加する

GNOME Shellのアクティビティ・オーバービューの左側にあるバー(Favorites Bar？)に、
メニューにでてこないアプリケーション(~/binに入っているやつとか)を登録するには、
手で.desktopファイルを作って(!)メニューに出せばいいようだ...

手順。ここではV2Cというアプリを例にする。

1. 適当な.desktopファイルを/usr/local/share/applicationsからコピる

cp -p /usr/share/applications/firefox.desktop ~/.local/share/applications/v2c.desktop

（Firefoxはいろいろ書いてあってあまりいい例ではないかも）

2. コピってきた.desktopファイルを編集する
vi ~/.local/share/applications/v2c.desktop


3. アクティビティ・オーバービューでNameに書いた名前を入力し、アイコンが表示されたらFavorites Barにドラッグアンドドロップ

これで登録できる。でてこなかったらAlt+F2と「r」でいったんGNOME Shellを再起動すればいいかも。

参考：http://askubuntu.com/questions/40382/how-to-add-a-folder-to-the-favorites-bar-in-gnome-shell

strlen(...) > 0とstrlen(...) != 0はどちらが速いか？

うまい文にならなかったが、貴重な結果なので以下にまとめておく。

Loquiでtopicを空にしようとしてもできない、というバグを発見して対応を施した際、
strlen(str)は>0がよいか？ != 0がよいか？という話になり、今のご時世問題になるわけのない、
「どちらが速いのか」が話題になった（というかした）
（バグは対策済み：対応内容はこちら https://bugs.launchpad.net/loqui/+bug/689164/comments/3)

結論としては、出力結果が同じになるので、速度は変わらない。しかし、変わらない理由が驚きであった。

話題となるのはこの部分：


上記の部分が入ったソース(irc_message.c)をgcc -Sでアセンブルし、if文のところを抜き出した結果がこちら：


前述の通り、strlen(...) > 0をstrlen(...) != 0にしても、出力結果は変わらないのだが、問題は
出力結果。strlenをコールしていないどころか、これではstr[0] != '\0'のようである。

strlen()の定義を追うと、eglibc-2.13/sysdeps/i386/i486/bits/string.hにあった：


このコードが使われている感じではないので、実際に使われているのはおそらくgccのbuiltin...
どうやらgccがstrlen(...) > 0自体を解釈しているようである。驚くべきgcc.

ちなみに、-O0でも一緒であるが、-fno-builtinをつけるとちゃんとstrlenをコールしてくれる：


まぁ、それでもsize_tがunsignedだったので、結局>0と!=0は出力結果は同じなのであったが。