调试 nasm 应用程序时 GDB 关闭一行

Question

I just encountered a weird issue with gdb , though I'm not sure, if I'm missing something. Let's suppose I have these two files:

somefile.asm :

01 section .text
02 
03 funca:
04  mov eax, 5
05  mov ebx, 5
06  cmp eax, ebx
07  je aisequal
08  mov ecx, 13
09  mov edx, 19
10  ret
11
12  aisequal:
13  mov ecx, 17
14  mov edx, 21
15  ret

and somefile_test.asm :

01 %include "somefile.asm"
02
03 section .text
04  global _start
05
06 _start:
07  xor eax, eax
08  xor ebx, ebx
09  xor ecx, ecx
10  xor edx, edx
11  call funca
12
13  mov eax, 1
14  mov ebx, 0
15  int 0x80

I compile and link it using

nasm -f elf -g -F dwarf somefile_test.asm 
ld -m elf_i386 -o somefile_test.out somefile_test.o

And then debug my application using gdb :

gdb somefile_test.out

I now set a breakpoint in the imported file:

GNU gdb (GDB) 10.1
(gdb) b somefile.asm:5
Breakpoint 1 at 0x8049000: file somefile.asm, line 5.
(gdb) r
Starting program: /<bla>/somefile_test.out

Breakpoint , funca () at somefile.asm:5
5       mov ebx, 5

Now appearantly, the execution stopped at the correct position. The next line to be executed would be 5, which is mov ebx, 5 . However , the last line should've been mov eax, 5 which should have already been executed. It was not:

(gdb) i r eax
eax            0x0                 0

It gets even weirder:

(gdb) si
6       cmp eax, ebx
(gdb) i r eax ebx
eax            0x5                 5
ebx            0x0                 0

Now, eax is set, but ebx is not (yet). If I execute the next line, it is set:

(gdb) si
7       je aisequal
(gdb) i r eax ebx
eax            0x5                 5
ebx            0x5                 5

However, I'd expect the program to jump to line 12 (aisequal) now, but it doesn't:

(gdb) si
8       mov ecx, 13

On the next instruction, it suddenly goes to the right line:

(gdb) si
14      mov edx, 21
(gdb) i r eax ebx edx
eax            0x5                 5
ebx            0x5                 5
edx            0x0                 0

And so on:

(gdb) si
15      ret
(gdb) i r eax ebx ecx edx
eax            0x5                 5
ebx            0x5                 5
ecx            0x11                17
edx            0x0                 0

If I put all my code in a single file, everything works as expected:

01 section .text
02  global _start
03
04 _start:
05  xor eax, eax
06  xor ebx, ebx
07  xor ecx, ecx
08  xor edx, edx
09  call funca
10
11  mov eax, 1
12  mov ebx, 0
13  int 0x80
14
15 funca:
16  mov eax, 5
17  mov ebx, 5
18  cmp eax, ebx
19  je aisequal
20  mov ecx, 13
21  mov edx, 19
22  ret
23
24  aisequal:
25  mov ecx, 17
26  mov edx, 21
27  ret

GBU gdb (GDB) 10.1
(gdb) b 16
Breakpoint 1 at 0x8049019: file singlefile.asm, line 16.
(gdb) r
Starting program: /<bla>/singlefile.out 

Breakpoint 1, funca () at singlefile.asm:16
16      mov eax, 5
(gdb) i r eax ebx ecx edx
eax            0x0                 0
ebx            0x0                 0
ecx            0x0                 0
edx            0x0                 0
(gdb) si
17      mov ebx, 5
(gdb) i r eax ebx ecx edx
eax            0x5                 5
ebx            0x0                 0
ecx            0x0                 0
edx            0x0                 0
(gdb) si
18      cmp eax, ebx
(gdb) si
19      je aisequal
(gdb) si
25      mov ecx, 17
(gdb) si
26      mov edx, 21
(gdb) i r eax ebx ecx edx
eax            0x5                 5
ebx            0x5                 5
ecx            0x11                17
edx            0x0                 0
(gdb) si
aisequal () at singlefile.asm:27
27      ret
(gdb) i r eax ebx ecx edx
eax            0x5                 5
ebx            0x5                 5
ecx            0x11                17
edx            0x15                21
(gdb) si
_start () at singlefile.asm:11
11      mov eax, 1

Now I've only picked up gdb two days ago, so I'm not that familiar with it. Can someone explain to me what's happening? Is this a bug or am I missing something?

I am using

nasm 2.15.05-1
binutils 2.35.1-1
gdb 10.1-4
gcc 10.2.0-4

on Linux 5.9.14-arch1-1 #1 SMP PREEMPT Sat, 12 Dec 2020 14:37:12 +0000 x86_64 GNU/Linux

Answer 1

Apparently, this is a regression in nasm.

Reported it to them.

Answer 2

This looks like a bug in nasm . It didn't reproduce for me using nasm-2.14 .

GDB will only display source info that the compiler/assembler tells it. If the assembler puts out incorrect info, then GDB will display that incorrect info and can't do anything about it.

To verify that the problem is in nasm , run objdump -dS somefile_test.o and compare the assembly and source listing. If they are also off by one, it's a bug in nasm .

Here is what I see:

somefile_test.o:     file format elf32-i386


Disassembly of section .text:

00000000 <funca>:
section .text

funca:
 mov eax, 5
   0:   b8 05 00 00 00          mov    $0x5,%eax
 mov ebx, 5
   5:   bb 05 00 00 00          mov    $0x5,%ebx
 cmp eax, ebx
   a:   39 d8                   cmp    %ebx,%eax
 je aisequal
   c:   74 0b                   je     19 <aisequal>

Note how instructions and source perfectly line up.