在机器代码中查找位置(gcc / objdump -d)

时间:2021-10-04 12:54:56

If you have a particular line of C code in mind to examine in the machine output, how would you locate it in objdump output. Here is an example

如果您在计算机输出中考虑了特定的C代码行,那么如何在objdump输出中找到它。这是一个例子

if (cond)
   foo;
   bar();

and I want to see if bar was inlined as I'd like. Or would you use some alternative tool instead of objdump?

我想看看栏是否按照我的意愿内联。或者你会使用一些替代工具而不是objdump?

4 个解决方案

#1


7  

You can start objdump using the -S option (like "objdump -Sd a.out"). It will display the sourcecode intermixxed with the assembler code, if the source-files the code was compiled from are available.

您可以使用-S选项启动objdump(例如“objdump -Sd a.out”)。如果编译代码的源文件可用,它将显示与汇编代码混合的源代码。

Alternatively, you can use the following way:

或者,您可以使用以下方式:

int main(void) {
    int a = 0;
    asm("#");
    return a;
}

becomes

       .file   "a.c"
        .text
.globl main
        .type   main, @function
main:
        leal    4(%esp), %ecx
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ecx
        subl    $16, %esp
        movl    $0, -8(%ebp)
#APP
# 3 "a.c" 1
        #
# 0 "" 2
#NO_APP
        movl    -8(%ebp), %eax
        addl    $16, %esp
        popl    %ecx
        popl    %ebp
        leal    -4(%ecx), %esp
        ret
        .size   main, .-main
        .ident  "GCC: (GNU) 4.3.2"
        .section        .note.GNU-stack,"",@progbits

#2


2  

You debugger should also let you see source code and matching assembly if you compiled with debug symbols. This is gcc option -g and gdb disass command.

如果使用调试符号编译,调试器还应该让您看到源代码和匹配程序集。这是gcc选项-g和gdb disass命令。

#3


1  

If you're compiling with gcc, you can use -S to generate an assembly file directly. This file usually has some useful information in it, including function names and sometimes line numbers for code (depending on the compile options you use).

如果您正在使用gcc进行编译,则可以使用-S直接生成程序集文件。该文件通常包含一些有用的信息,包括函数名称和有时代码的行号(取决于您使用的编译选项)。

#4


0  

Function calls are detected in the assembly by the common function prolog.

通用函数prolog在程序集中检测函数调用。

With i386 it is

有了i386,它就是

  55      push %ebp
  89 e5   mov %esp, %ebp
  ...
  c9      leave # optional
  c3      ret

with amd64/x86_64 is is similar (just the quad prefix 48):

与amd64 / x86_64类似(只是四元组前缀48):

  55                    push   %rbp
  48 89 e5              mov    %rsp,%rbp
  ..
  c9                    leaveq # optional
  c3                    retq   

So when you detect that inside your objdump -S bla.o or gcc bla.c -g -fsave-temps -fverbose-asm output of your main function and for bar also, bar is not inlined. Also when main has a call or jump to bar it is not inlined.

所以当你在你的主函数的objdump -S bla.o或gcc bla.c -g -fsave-temps -fverbose-asm输出中检测到时,bar也没有内联。此外,当主要有一个电话或跳转到酒吧时,它没有内联。

In your case you could see if bar has local vars, which needs room on the local stack. If bar is inlined the stack adjust (e.g. sub $0x8,%esp) is done right after the main prolog, main could access that var. If not it is private to bar.

在您的情况下,您可以看到bar是否具有本地变量,这需要本地堆栈上的空间。如果bar是内联的,则在主prolog之后立即完成堆栈调整(例如,子$ 0x8,%esp),main可以访问该var。如果不是它是私人酒吧。

#1


7  

You can start objdump using the -S option (like "objdump -Sd a.out"). It will display the sourcecode intermixxed with the assembler code, if the source-files the code was compiled from are available.

您可以使用-S选项启动objdump(例如“objdump -Sd a.out”)。如果编译代码的源文件可用,它将显示与汇编代码混合的源代码。

Alternatively, you can use the following way:

或者,您可以使用以下方式:

int main(void) {
    int a = 0;
    asm("#");
    return a;
}

becomes

       .file   "a.c"
        .text
.globl main
        .type   main, @function
main:
        leal    4(%esp), %ecx
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ecx
        subl    $16, %esp
        movl    $0, -8(%ebp)
#APP
# 3 "a.c" 1
        #
# 0 "" 2
#NO_APP
        movl    -8(%ebp), %eax
        addl    $16, %esp
        popl    %ecx
        popl    %ebp
        leal    -4(%ecx), %esp
        ret
        .size   main, .-main
        .ident  "GCC: (GNU) 4.3.2"
        .section        .note.GNU-stack,"",@progbits

#2


2  

You debugger should also let you see source code and matching assembly if you compiled with debug symbols. This is gcc option -g and gdb disass command.

如果使用调试符号编译,调试器还应该让您看到源代码和匹配程序集。这是gcc选项-g和gdb disass命令。

#3


1  

If you're compiling with gcc, you can use -S to generate an assembly file directly. This file usually has some useful information in it, including function names and sometimes line numbers for code (depending on the compile options you use).

如果您正在使用gcc进行编译,则可以使用-S直接生成程序集文件。该文件通常包含一些有用的信息,包括函数名称和有时代码的行号(取决于您使用的编译选项)。

#4


0  

Function calls are detected in the assembly by the common function prolog.

通用函数prolog在程序集中检测函数调用。

With i386 it is

有了i386,它就是

  55      push %ebp
  89 e5   mov %esp, %ebp
  ...
  c9      leave # optional
  c3      ret

with amd64/x86_64 is is similar (just the quad prefix 48):

与amd64 / x86_64类似(只是四元组前缀48):

  55                    push   %rbp
  48 89 e5              mov    %rsp,%rbp
  ..
  c9                    leaveq # optional
  c3                    retq   

So when you detect that inside your objdump -S bla.o or gcc bla.c -g -fsave-temps -fverbose-asm output of your main function and for bar also, bar is not inlined. Also when main has a call or jump to bar it is not inlined.

所以当你在你的主函数的objdump -S bla.o或gcc bla.c -g -fsave-temps -fverbose-asm输出中检测到时,bar也没有内联。此外,当主要有一个电话或跳转到酒吧时,它没有内联。

In your case you could see if bar has local vars, which needs room on the local stack. If bar is inlined the stack adjust (e.g. sub $0x8,%esp) is done right after the main prolog, main could access that var. If not it is private to bar.

在您的情况下,您可以看到bar是否具有本地变量,这需要本地堆栈上的空间。如果bar是内联的,则在主prolog之后立即完成堆栈调整(例如,子$ 0x8,%esp),main可以访问该var。如果不是它是私人酒吧。