タグ

binaryに関するnamikisterのブックマーク (15)

  • 第6回(最終回) 関数の機能 ~ 関数間での連携 | gihyo.jp

    前回は、関数[1]が呼ばれた際に、関数内での局所的な情報をどのように管理するかについて説明しました。 今回は、関数呼び出しにおける連携方法について説明しようと思います。 引数と戻り値 引数 関数の呼び出し元は、さまざまな形式で引数を指定します。たとえば、 自身の局所変数の値 自身に指定された引数 他の関数の呼び出し結果 上記の値から導出された値(例: 四則演算/構造体参照等) 一方で(一般的な)言語仕様上から見て、呼び出された側にとっての引数は、関数終了まで領域が保持されている=終了後は必要ない、という点では局所変数と実質的に差異がありません。 そのため、Intel x86アーキテクチャで関数呼び出しを実現する場合、呼び出し元は引数をスタック上に格納します。 リスト1 呼び出し元での引数格納 movl $1, 0(%esp) movl $15, 4(%esp) 呼び出し先の関数は、スタック

    第6回(最終回) 関数の機能 ~ 関数間での連携 | gihyo.jp
  • 第4回 "case" の事情 | gihyo.jp

    前回は条件分岐を行うためのEFLAGSレジスタと条件分岐命令について説明しました。 しかし、プログラミングにおける重要な制御構造でありながら、単純な条件分岐では実現できないものとして、C/C++言語で言うところのswitch構文があります。 今回は、このswitch構文について、アセンブラの視点から見てみましょう。 if分岐の限界 たとえば: 変数 "x" に格納された値が0, 1, 2, 3, およびそれ以外の場合に、それぞれ異なる処理を行いたい。 という状況で、あまり手馴れていない人の実装は往々にして以下のようになります。 リスト1 if 分岐による実装 if(x == 0){ .... } else if(x == 1){ .... } else if(x == 2){ .... } else if(x == 3){ .... } else{ .... } 上記の例は、「⁠それ以外」

    第4回 "case" の事情 | gihyo.jp
  • 第2回 メモリに始まりメモリに終わる|gihyo.jp … 技術評論社

    上記はEAXレジスタに対する表記例ですが、16ビット長に関する表記は他の全ての汎用レジスタに対して、8ビット長に関する表記はEBX、ECX、EDXに対して適用することができます。 直接アドレッシング/間接アドレッシング 取り扱い対象を直接指定するのが「直接アドレッシング⁠」⁠、指定したものをアドレス値とみなしてメモリ領域(あるいはそこに格納された値)を取り扱うのが「間接アドレッシング」です。 以下に、レジスタ指定/値指定との組み合わせの例を示します。 リスト4 直接/間接アドレッシング .data .align 4 .global value value: .long 1 .text .align 4 .global entry_point entry_point: int3 # プログラム実行の一時停止 # 転送元: value 領域の格納値(間接) # 転送先: レジスタ eax(直接

    第2回 メモリに始まりメモリに終わる|gihyo.jp … 技術評論社
  • Wataru's memo(2008-03-05)

    ● [Thoughts] プログラマの教養は manual pages に宿る (その4) Linux/GNU 開発環境の役者が揃ったところで、実際にプログラムのビルドに挑戦してみましょう。 最初に binutils ありき 全ての環境において、もっとも原始的かつ基的な開発ツールは、アセンブラとリンカです。昔のアセンブラは、そのまま実行可能ファイルを出力できていたのですが(a.out の名前は Assembler OUTput に由来)、GNU 開発環境ではアセンブラ (as: ASsembler) が出力したオブジェクトファイルから、リンカ・ローダ (ld: linker LoaDer) が実行可能ファイルを出力します(Netwide Assembler: NASM を利用すれば、アセンブラ単体で実行可能ファイルを生成可能)。 アセンブラ (as) とリンカ・ローダ (ld) は、GN

  • Wataru's memo(2008-03-04)

    ● [Thoughts] プログラマの教養は manual pages に宿る (その3) 早速、Cソースからの実行可能ファイル作成に進みたいところですが、その前に作業環境を確認しておきましょう。 Linux/GNU 開発環境の確認方法 私が使用している Linux/GNU 開発環境は以下の通りです。 $ uname -a Linux debian64 2.6.22-3-amd64 #1 SMP Sun Nov 4 18:18:09 UTC 2007 x86_64 GNU/Linux オペレーティングシステム環境を簡単に知るためには、uname (Uts NAME: UTS = Universal Time-sharing System / Unix Time-sharing System) コマンドを使います。この Linux マシンは Core 2 プロセッサ搭載のため、Debian

    namikister
    namikister 2008/03/07
    Cのプログラムをコンパイルするときに必要となるものたちについて.勉強になるなぁ
  • Perl で 8ビット CPU を作る - naoyaのはてなダイアリー

    CPU を作る、と言ってもハードではなくソフト、仮想機械です。 2001 年から UNIX USER で連載されていた西田亙さんの「gccプログラミング工房」。いまさらながら、バックナンバーを取り寄せて初回から順番に読んでいます。とてもためになる連載です。 この連載中で第10回から数回に分けて開発されていた octopus という 8 ビット CPU の仮想機械があります。オリジナルは C 言語で書かれていたのですが、その設計を見て、これは他の言語でも作れるのではないか、と思い Perl に移植してみたところなんとか動作させることができました。以下の URL にコードを公開します。(西田さんに確認を取ったところ、オリジナルのソースは Public Domain とのことでした。オリジナルは http://www.skyfree.org/jpn/unixuser/ からダウンロード可能です。

    Perl で 8ビット CPU を作る - naoyaのはてなダイアリー
  • google-perftoolsを別のCPUに移植してみた - memologue

    google-perftoolsというx86,x86_64,ppcなUNIX向けのプロファイラの(cpu-profiler部分)を、armなLinuxに対応させてみました。何かの役に立つかもしれないので、patchおよびpatch作成作業のメモを載せます。arm-v5tアーキテクチャ(ARM9系)向けの移植です。 Linux/ARM向けのソフトウェアのパフォーマンスを解析したいなぁと思うことがあったのですが、OProfileはカーネル入れ替えがめんどくさい、gprofはプロファイル専用のバイナリを作成するのがめんどくさい、プロプラな奴は興味ないということで移植しました。移植の方がめんどくさいだろという話もありますが。perftools自体の説明はこちらが便利です。あーそういえばAndroidもARMでしたっけ? パッチ http://binary.nahi.to/google-perfto

    google-perftoolsを別のCPUに移植してみた - memologue
    namikister
    namikister 2007/12/04
    よくわからんけど,バイナリハッカーかっこいい.理解できるようになりたいなぁ
  • IBM Developer

    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.

    IBM Developer
  • ついカッとなって実行バイナリにパッチ - memologue

    とある都合で、ソフトウェア開発の際にソースコードの提供されていないツールを使うことになりました。x86なLinux上で動く、ちょっとしたtoolchainです。が、そのツールの処理速度が遅く、入力サイズに対して、結果が出てくるまでの時間がどうもO(N^2)かそれよりひどい。遅くてイライラするので、昨晩ついカッとなってパッチを当てました。そのメモです。また、ありがちな事態(?)な気もするので、みなさんどうしてるのかなー的なお伺いも兼ねて。 ボトルネックの特定 そのツール(以下A)の実行バイナリはstripされておらず.symtabが残っていました。のでまず、どこが遅いのかgoogle-perftoolsをLD_PRELOADしてそのソフトウェアを実行し、実行プロファイルを取りました。すると、嬉しいことにある一つの関数(以下F)で全体の90%以上の時間を消費していることがわかりました。関数Fは

    ついカッとなって実行バイナリにパッチ - memologue
  • Wataru's memo(2007-04-11)

    ● [Linux][Writing] 世界一単純な実行ファイルフォーマット binfmt_flat Computer Architecture Series 第二作のために、日々素材作りを進めているのですが、この作業の間に "binfmt_flat" というオタッキーなモジュールが誕生しました。今日は、このモジュールを使った "Hello golf" をご紹介しましょう(注: 昨年一世を風靡した ELF golf ではありませんので、あしからず)。 初学者の理解を阻む複雑な ELF 皆さんご存じの通り、PC-UNIX 上における標準のオブジェクトファイルフォーマットは ELF (Executable and Linking Format) ですが、このフォーマットは高機能を追求しているため、内部はかなり複雑な作りになっています。 実は、当初 Computer Architecture Se

  • hogetrace - 関数コールトレーサ - memologue

    でかいソフトウェアの、大量のソースコードを短時間で読む必要が生じたので、その補助ツールとしてptrace(2)ベースのLinux用関数トレーサを自作しました。こういうツール上でまずソフトウェアを実行してみて、どのファイルのどの関数がどういう順で呼ばれるか把握おけば、いきなりソースコードの山と格闘を始めるより楽かなーと思いまして。せっかく作ったので公開します。 http://binary.nahi.to/hogetrace/ straceはシステムコールだけ、ltraceは共有ライブラリ(DSO)の関数呼び出しだけ*1をトレースしますが、このツールは、実行バイナリ中の自作関数の呼び出しもトレースします。例えば再帰で1から10まで足し算するソースコードを用意して % cat recursion.c #include <stdio.h> int sum(int n) { return n ==

    hogetrace - 関数コールトレーサ - memologue
  • Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー

    Linux カーネルのプロセススケジューラの核である kernel/sched.c の schedule() を読み進めていくと、タスク切り替え(実行コンテキスト切り替え)はその名も context_switch() という関数に集約されていることが分かります。2.6.20 の kernel/sched.c だと以下のコードです。 1839 static inline struct task_struct * 1840 context_switch(struct rq *rq, struct task_struct *prev, 1841 struct task_struct *next) 1842 { 1843 struct mm_struct *mm = next->mm; 1844 struct mm_struct *oldmm = prev->active_mm; 1845 184

    Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー
  • hello worldなELFバイナリを出力するCのプログラム(の一番単純な奴) - memologue

    こちらの記事(Binary HacksのHack #25の軽い補足)は、「インラインアセンブラをちょっとだけ使って、gccに小さなhello worldバイナリを出力させる」というお話でした。一方、小さいHello Worldが欲しかったら、gccにELF実行バイナリを出力させるのではなく、「自力でELFを吐くCのコードを書いてしまう」手もあります。ご利用のCPUのアセンブリ言語がわかるのでしたら、こっちの方法でHello Worldするのも悪くないですね。こちらの方法でしたら、「急にbrainf*ckのコンパイラが書きたくなった*1」などの非常によくあるシチュエーションにも応用が効きますしー。 ELF直書きって、なんかすごく難しいように思われていると思うんですが(いや、DSO吐いたりするのは実際面倒ですが)、hello worldくらいだったらなんてことないです。次の4つの処理を順に行え

    hello worldなELFバイナリを出力するCのプログラム(の一番単純な奴) - memologue
  • オブジェクトファイルについて

    はじめに Binary Hacks の校正大会にて、あーセクションの話が少し説明不足で不親切だね、っていう話が出ました。あった方がいいかな、と思ったので、宣伝を兼ねて、ここに私が知っていることを書いておきます。 内容としては、 Binary Hacks に比べてかなりいい加減に書いています。例えば調べものは一切せずに書きます。著者の中で最もいい加減な私がよりもいい加減に書いたということで、 Binary Hacks の全ての文章はこれよりはレベルが上、というようなサンプルだと思って下さい。宣伝を兼ねるということで、これ単体ではフォローせずに Binary Hacks のここを見てね、というポインタだけ示す部分が多いです。『』で囲まれた文字列は Binary Hacks の中のハック名に対応しています。 書いてる最中なので、気が向いたら内容を追加します。 詳しい参考文献としては Linke

  • 実行回数を記憶している実行ファイル - 兼雑記

    http://d.hatena.ne.jp/alohakun/20061113 を見てて、騙されてはいけない! id:yupo5656 さんは僕らの自由を奪う詐欺師だっ…とか思ったので適当に。 ELFヘッダは e_ident という 16Byte のメンバから始まっています。ここは magic を記録する場所です。 magic については Binary Hacks #4 見てね☆とかそんな感じで。 でまぁ、最初の 4Byte 、 "\x7fELF" までは、無いと動きませんし、しぶしぶつけるわけですが、残りの 12Byte は "Hello world\n" を埋めるための空間です…と思ってたらなんか プロゴルファーは実行コード埋めてた というようなのが今までの粗すぎる粗筋なのですが、たしか高林さんがファイルのパーミッションか時刻情報あたりでカウンタ実現してたなぁ(でもURL見つからないな

    実行回数を記憶している実行ファイル - 兼雑記
  • 1