すべての行の後に.CFIディレクティブがあるようです。また、.cfi_startproc
、.cfi_endproc
など、さまざまなものがあります。 more here 。
.file "temp.c"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq %rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl $0, %eax
leave
ret
.cfi_endproc
.LFE0:
.size main, .-main
.globl func
.type func, @function
func:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq %rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl %edi, -4(%rbp)
movl %esi, %eax
movb %al, -8(%rbp)
leave
ret
.cfi_endproc
.LFE1:
.size func, .-func
.ident "GCC: (Ubuntu 4.4.1-4ubuntu9) 4.4.1"
.section .note.GNU-stack,"",@progbits
私はこれらの目的を理解できませんでした。
Call Frame Information の略で、GNUコールフレームを管理するAS拡張機能です。From DeveloperWorks :
一部のアーキテクチャでは、例外処理はCall Frame Informationディレクティブで管理する必要があります。これらのディレクティブは、例外処理を指示するためにアセンブリで使用されます。これらのディレクティブは、何らかの理由(コードベースの移植性など)でGCCが生成した例外処理情報では不十分な場合、Linux on POWERで使用できます。
これらは例外処理の必要性に応じていくつかのプラットフォームで生成されるようです。
これらを無効にする場合は、 David's answer をご覧ください。
これらを無効にするには、gccオプションを使用します
-fno-asynchronous-unwind-tables
これは本当に古いスレッドですが、これはcfi_startprocのgoogleでの最高の結果であるため、多くの人がおそらくこの出力を無効にするためにここに来ることに注意してください。
-fno-dwarf2-cfi-asm
も必要になる場合があります。
CFIディレクティブはデバッグに使用されます。デバッガーがスタックを巻き戻すことができます。たとえば、プロシージャAがプロシージャBを呼び出し、次にプロシージャBが共通プロシージャCを呼び出す場合、プロシージャCは失敗します。誰が実際にCを呼び出したかを知りたいのですが、Bを呼び出したのは誰かを知りたいかもしれません。
デバッガは、スタックポインタ(%rsp)とレジスタ%rbpを使用してこのスタックを巻き戻すことができますが、それらを見つける方法を知る必要があります。そこでCFIディレクティブが登場します。
movq %rsp, %rbp
.cfi_def_cfa_register 6
ここの最後の行は、「Call frame address」がレジスタ6(%rbp)にあることを示しています