KMC Staff Blog:GNU ldのwrap機能でC++メンバ関数をwrapする例
2018年12月14日 GNU ldのwrap機能でC++メンバ関数をwrapする例 GNU ld には wrap という機能があります。これはリンク時に、未定義（Undefined）のシンボル foo を __wrap_foo として解決し、元のシンボルを __real_foo として解決するという機能です。これを利用すると、バイナリ提供のライブラリ関数を差し替えることが可能になります。 C での使用例はネット上にたくさん存在しますが、C++ の例がほとんど見つからなかったのでメモしておきます。 C でも C++ でも、リンカから見ればどちらもただのシンボル（文字列）なので、C++ でも wrap 機能は使用できるのですが、C++ の場合はシンボルが名前マングリングされる点が大きく異なります。 そのため、__wrap_ 関数を C++ で定義することはできないので、C 関数、または ex
KMC Staff Blog:GCC 7以前のAArch64ターゲットでlibgccをビルドする時に-fomit-frame-pointerを付けるとC++例外が正しく動かなくなる問題
2018年09月20日 GCC 7以前のAArch64ターゲットでlibgccをビルドする時に-fomit-frame-pointerを付けるとC++例外が正しく動かなくなる問題 タイトルが本記事の内容のほぼ全てです。自分で libgcc をビルドするという奇特（誤用）な人以外には関係無い話ですが（※）、まあこんなこともあるんだなと。 おそらく Linux (aarch64-linux-gnu) ターゲット等でも共通だと思うのですが、現象を確認したのはベアメタル (aarch64-elf) ターゲットで、GCC 5.1/6.3 です。7.2 では発生しませんでした。（4 系でも発生すると思いますが、そもそも AArch64 のサポートが 4.8 からなので、枯れてるとは言い難い 4 系の使用自体が現在では非推奨だと思います。） この問題は、半年ほど前、弊社の製品である exeGCC の開発
KMC Staff Blog:#include_nextの疑問メモ
2014年09月18日 #include_nextの疑問メモ 前回の記事で、GNU CPP の独自拡張 #include_next 指令を紹介しました。 「GNU CPP(GCC)の独自拡張#include_next指令」 このドキュメントは簡単な概要と例だけなので、ちょっと複雑なケースになると、この挙動は仕様なのか？バグなのか？という判断が難しくなります。 この間、私が悩んだ疑問は、過去に以下の ML で取り上げられた疑問とほぼ同じものでした。 gcc-help ML: #include_next: wrong search order? この疑問を単純化して解説した後、私なりの解釈を説明します。 まず、GNU CPP は、#include や #include_next 指令を見つけると、gcc-include-dir（GCC 独自のインクルードファイルが含まれるディレクトリ）、sys
KMC Staff Blog:GNU CPP(GCC)の独自拡張#include_next指令
2014年09月11日 GNU CPP(GCC)の独自拡張#include_next指令 Warp の挙動を調べている時に、GCC のプリプロセッサの #include_next 指令の挙動にかなり悩んだので、備忘録も兼ねてドキュメントの日本語訳をアップロードします。 厳密な仕様が無く、あまり有名でもない（？）独自拡張なので（ARM CC や IBM XL C/C++ など、一応 GCC 以外のコンパイラのプリプロセッサにも取り入れられているようですが）、情報が少なく、実際にいろいろ動かして実験してみないと挙動がよくわからず、かなり混乱しました。以下の翻訳もあまり自信が無いので、何かお気づきの点があれば、コメント欄にてご指摘いただけると幸いです。（ただし、現在スパムコメントがあまりにも多いため、半角英数字のみのコメント、国外の IP アドレスからのコメント、改行が 10 個以上あるコメント
KMC Staff Blog:環境変数でLinuxのglibc動的リンカにログを出力させる
2014年09月05日 環境変数でLinuxのglibc動的リンカにログを出力させる たまには役に立ちそうなネタも書かないとということで、この間社内で話題※になった、glibc 環境の Linux の動的リンカに共有ライブラリのデバッグ時に有益な情報を出力させる方法を紹介します。 ※ この Tips は、弊社の PARTNER-AP（JTAG-ICE デバッガではなく、Linux アプリをデバッグするためのアプリデバッガ）案件で役に立った実績のある Tips なので、glibc と共有ライブラリを使用するような、比較的リッチな Linux 環境において有効です。（デバッガとは無関係で、純粋に Linux 環境でのデバッグ機能の紹介となります。） Linux のアプリが大規模になってくると、非常に大量の共有ライブラリを動的ロードすることとなり、実際にどの共有ライブラリがどんな風にロードされて
KMC Staff Blog:C/C++プリプロセッサの挙動の違い（defined編）
2014年08月21日 C/C++プリプロセッサの挙動の違い（defined編） 前回の記事でビルドした Facebook 社の Warp の挙動を調べていた所、#if や #elif 指令中でのみ使用可能な defined 単項演算子の挙動が GCC のプリプロセッサと異なり、GCC 用のヘッダを前処理できない事例を発見したので、その時のメモです。 以下のような、現象が再現する最小コード片を用意しました。 $ cat defined_test.c #define FOO defined (BAR) #define BAR #if FOO #endif これは warp.exe ではエラーになります。FOO の最初のマクロ展開の時に defined 演算子の引数の BAR も一緒に #if defined() のように展開（削除）され、エラーになっているように思われます。 $ ./warp
KMC Staff Blog:GCCのトランザクションメモリサポート
2014年01月23日 GCCのトランザクションメモリサポート GCC のリリースノートを眺めていたら、4.7 からトランザクションメモリのサポートが入っていたことに気付いたので、少し調べてみました。 ・トランザクションメモリとは？ トランザクションメモリは、マルチスレッドプログラムにおいて、複数のスレッドからアクセスされる共有変数（メモリ）を保護するためのしくみのようです。 共有変数の保護には、従来は mutex などのロックが使用されてきました。しかし、ロックを使用したプログラム片（関数など）は、ロックの取得と解放の順番が重要なので、基本的には入れ子にできないという問題があります。常にプログラム全体に散らばるロックを意識する必要があるので、プログラムの部品化や再利用が困難になりますし、デッドロックのデバッグや品質保証は非常に高コストになりがちです。 一方トランザクションメモリは、原理的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KMC Staff Blog:64bit Ubuntu上でshターゲットのWindows用gccをカナディアンクロスビルドすると発生する不具合