标签: objdump

我用来aarch64-linux-gnu-objdump反汇编 ARM v8 程序的一部分。它适用于 V8 64 位指令，但当模式更改为 V7 指令集（A32）时会失败 - 代码以 V8 指令集开始，切换到 A32（AArch32 执行状态），然后切换到T32拇指指令集。如何反汇编A32和T32指令？当模式切换时，我是否需要将代码分解为多个部分，以便我有单独的指令模式块？

如有任何帮助，我们将不胜感激

这在下面的文件中意味着什么？2**2和2**0

$ objdump -h main.o

main.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000000b  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000040  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000040  2**2
                  ALLOC
  3 .note.GNU-stack 00000000  00000000  00000000  00000040  2**0
                  CONTENTS, READONLY, CODE

我有一个包含 ARM v8 二进制代码的文件。我想反汇编文件并获取其中包含的实际汇编代码。

假设文件名是 tmp.o 我运行：

/opt/linaro/A64-tools/bin/aarch64-linux-gnu-objdump -b binary -m AARCH64 -D tmp.o

这给了我正确的反汇编。但是，分支指令的偏移量假定此代码位于地址 0x00000000 中。

如果我知道代码将位于内存中的地址 0x12345678 中：

1. 有没有办法告诉 objdump 使用这个地址作为起始地址？

2. 如果没有，我可以在二进制文件中添加一些标头，其内容如下：

   . = 0x12345678

提前致谢..

当我使用命令“arm-linux-gnueabihf-objdump -d a.out”反汇编一个简单的 ARM 二进制文件时，得到以下输出

00008480 <_start>:
8480:   f04f 0b00   mov.w   fp, #0
8484:   f04f 0e00   mov.w   lr, #0
8488:   bc02        pop {r1}
848a:   466a        mov r2, sp

这里不同的列代表什么？例如，8480 和 f04f 0b00（来自代码的第二行）

我正在检查使用以下命令编译的 C 文件的 objdump：

riscv64-unknown-elf-gcc -O0 -o maxmul.o maxmul.c
riscv64-unknown-elf-objdump -d maxmul.o > maxmul.dump

奇怪的是（或没有）这些地址似乎没有在 32 位字上对齐，但实际上是在 16 位边界上对齐。

谁能解释一下为什么吗？

谢谢。

objdump 摘录：

00000000000101da <main>:
   101da:   7155                    addi    sp,sp,-208
   101dc:   e586                    sd  ra,200(sp)
   101de:   e1a2                    sd  s0,192(sp)
   101e0:   0980                    addi    s0,sp,208
   ...

C代码：

int main()
{

  int first[3][3], second[3][3], multiply[3][3];
  int golden[3][3];
  int sum;

  first[0][0] = 1;  first[0][1] = 2;  first[0][2] = 3;
  first[1][0] = 4;  first[1][1] = 5;  first[1][2] = 6;
  first[2][0] = 7;  first[2][1] = 8;  first[2][2] = …

在我的objdump -t输出中，我看到以下两行：

00000000000004d2 l     F .text.unlikely 00000000000000ec function-signature-goes-here [clone .cold.427]

和

00000000000018e0 g     F .text  0000000000000690 function-signature-goes-here

我知道l意味着本地，也g意味着全球。我还知道这.text是目标文件中的一个部分或一种类型的部分，包含已编译的程序指令。但什么是.text.unlikely？假设它是一个不同的部分（或部分类型）.text- 有什么区别？

我在寻找替代的readelf和objdump二重奏使用Visual Studio编译C++源代码和调查时lib,obj和dll.

我知道MinGW提供了这个工具的移植,但我正在寻找官方支持Microsoft C++ ABI的东西.

如果这件事,我正在使用Visual Studio 2012.

谢谢.

使用objdump命令:

$ objdump -M att -d  wrapping_counters_test   

我制作了这个列表(这只是整个列表中的一个片段):

100000ae5:   31 ed                   xor    %ebp,%ebp
100000ae7:   31 d2                   xor    %edx,%edx
100000ae9:   49 89 c4                mov    %rax,%r12
100000aec:   b8 00 ca 9a 3b          mov    $0x3b9aca00,%eax
100000af1:   66 66 66 66 66 66 2e    data16 data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1)
100000af8:   0f 1f 84 00 00 00 00
100000aff:   00
100000b00:   8d 75 01                lea    0x1(%rbp),%esi

data16第二mov条指令后面的s 行是什么意思？

我在汇编中有以下代码：

global _start
section .rodata
  hello: db "Hello World!", 10

section .text

_start:
    mov eax,4           
    mov ebx,1          
    mov ecx,hello       
    mov edx,13     
    int 80h             

    ; Terminate program
    mov eax,1          
    xor ebx,ebx           
    int 80h

如果我使用以下代码的objdump，则会得到：

如果我在objdump中得到了NUL字符，则将无法完成我正在处理的任务。我如何在没有任何NUL（0x00）字节的情况下获取objdump？

为什么要剥离二进制显示_cxa_finalize而不是libc_start_main？

我正在尝试main()在Linux（Ubuntu）上的一个非常简单的C程序中查找和反汇编。二进制文件被剥离。在下面，您可以看到相同说明的拆卸（未剥离）与拆卸（剥离）。

问题：_cxa_finalize剥离版本中包含什么？为什么libc_start_main被替换_cxa_finalize？

不剥离：

106d:   48 8d 3d c1 00 00 00    lea    rdi,[rip+0xc1]        # 1135 <main>

1074:   ff 15 66 2f 00 00       call   QWORD PTR [rip+0x2f66]        # 3fe0 <__libc_start_main@GLIBC_2.2.5>

剥离：

106d:   48 8d 3d c1 00 00 00    lea    rdi,[rip+0xc1]        # 1135 <__cxa_finalize@plt+0xf5>

1074:   ff 15 66 2f 00 00       call   QWORD PTR [rip+0x2f66]        # 3fe0 <__cxa_finalize@plt+0x2fa0>