我正在用gdb调试一个非常简单的代码:
mov ebp,eax ; Save # of bytes read from file for later
这是我的输出:
Breakpoint 2, Read () at hexdump1.asm:44
(gdb) info register eax
eax 0xd 13
(gdb) step
Read () at hexdump1.asm:45
(gdb) info register ebp
ebp 0xd 0xd
为什么gdb为eax显示0xd 13,而ebp显示0xd 0xd?
让我向您展示以下简单的C代码:
int main()
{
int i;
for (i = 0; i < 256; i++)
{
i++;
}
}
在这段简单的C代码中,如果我们使用Clang编译并调试它:我们将得到如下结果:
(gdb) b main
Breakpoint 1 at 0x100000f7b: file a.c, line 5.
(gdb) r
Starting program: a.out
[New Thread 0x1403 of process 23435]
warning: unhandled dyld version (15)
T
我正在做一个项目,我似乎无法调试我的代码。首先,我认为这是我的IDE (Eclipse)中的一个配置错误,但后来发现它根本无法工作,甚至对于下面这样的单个程序,gdb也不起作用。
test.c
void main() {
int a=1;
int b=2;
int c=3;
a=b+2; // line 5: breakpoint is set here
c=a+b;
b=c+3;
return;
}
user@mycomputer:/home/user/test$ gcc -g -O0 -c test.c
user@mycomputer:/home/user/t
我在linux上用nasm编写汇编语言程序。问题是在使用gdb进行调试时,它不会在_start函数中执行步骤,并给出“单步执行直到退出函数_start”的消息。
此外,当我在第1行之后设置断点时,它说:
(gdb) break 2
Note: breakpoints 1 and 2 also set at pc 0x4000b0.
Breakpoint 3 at 0x4000b0: file new3.asm, line 2.
(gdb) break 3
Note: breakpoints 1, 2 and 3 also set at pc 0x4000b0.
Break
我们在windows上的汇编程序和一些英特尔电脑上运行学生。在使用布局时,gdb在msys2下失败。我能够让它在CMD窗口上工作,但如果:
gdb myexe
layout src
b main
r
程序崩溃。有时窗户是锁着的
如果我们第一次在命令行模式下运行,它就能工作:
gdb myexe
b main
r
然后
layout src
或
layout asm
layout reg
这既令人不安又可怕。我们不能重新运行任何东西,总是必须终止调试器并重新开始。
在MacOSX蒙特雷12.0.1 (英特尔MacBook Pro 2019),我们也有类似的问题。我们安装了gdb 12.1
gdb
当我使用list *func+offset在gdb中查看src时,第二行回显使我感到困惑,第304行和*rte_ring_create_elem+0x1cc之间的关系是什么。
(gdb) l *rte_ring_create_elem+0x1cc
0x9f744 is in rte_ring_create_elem (src/lib/librte_ring/rte_ring.c:309).
304 src/lib/librte_ring/rte_ring.c: No such file or directory.
下面是带有行号的dpdk src。
294 mz = rte
目前正在尝试用KDbg / gdb调试来自的河内塔的源代码(很棒的参考资料)
因为我想回顾一下堆栈是如何在这个问题中使用的,所以我用NASM组装了它,并使用GCC将其链接起来。然而,我注意到在KDbg中,当前的执行点没有更新(即,我不知道我在文件中的什么位置)。因为KDbg依赖于gdb,所以我在gdb中运行了代码,看看我是否遇到过类似的问题。
如果我在程序中的第30行(即main函数中的一行)上设置了断点,则会得到以下结果:
(gdb) break 30
Breakpoint 2 at 0x804840b: file hanoi.asm, line 30.
(gdb) next
Single
当我使用jmp时,我有一个分割错误。
第一次,我只使用jmp 0x30,我得到了分割错误。
我使用gdb对我的程序进行了调试,我看到在调用jmp之后,它跳到了一个绝对地址。
(gdb) b main
Breakpoint 1 at 0x80483b7: file f.c, line 3.
(gdb) r
Starting program: /root/work/f
Breakpoint 1, main () at f.c:3
3 __asm__("jmp 0x30\n"
(gdb) n
0x00000030 in ?? ()
(gdb)
我认为它可能是一个相对地址
我注意到我的程序在i386和arm/EABI之间的行为不同,我使用strace运行它,并且看到pread64参数在arm/EABI上不正确。
我使用gdb运行程序,查看catch syscall pread64 info registers,没有发现任何问题。
我强迫syscall参数,然后注意到第四个参数实际上不会改变任何东西。更改参数顺序/使用对于特定的体系结构是有效的。
long syscall6_i386(long nr, long p0, long p1, long p2, long p3, long p4, long p5){
register long _r __asm_
我有一个源代码:
; hello.asm a first program for nasm for Linux, Intel, gcc
;
; assemble: nasm -f elf -l hello.lst hello.asm
; link: gcc -o hello hello.o
; run: hello
; output is: Hello World
SECTION .data ; data section
msg: db "Hello World",10 ; the string to pr
我有以下汇编代码:
; File: strrev.asm
; A subroutine called from C programs.
; Parameters: string A
; Result: String is reversed and returned.
SECTION .text
global strrev
_strrev: nop
strrev:
push ebp
mov ebp, esp
; registers ebx,esi, and edi must be saved if used
push ebx
p