GDB不加载NASM的源线

Question

我正在使用NASM组装X86-64程序：

nasm -f elf64 -g -F dwarf -o foo.o foo.asm
ld -o foo foo.o

来源：

section .text
    global _start
_start:
    mov rax, 60     ;SYS_exit
    mov rdi, 0      ;EXIT_SUCCESS
    syscall

使用GDB调试程序并未显示指令来自哪个文件或行号。例如， break _start 显示“断点1在0x401000”，而不是“断点1 at 0x400080：file foo.asm，第4行4”。如下所示，博客文章。切换到布局regs 显示“没有可用源”，而不是在源中找到当前指令。 List 确实显示了源，但是在步入下一个指令时，它会切换回“无可用源”。

objdump -g foo 似乎表明所需的调试信息在那里：

foo:     file format elf64-x86-64
...
The File Name Table (offset 0x1c):
  Entry Dir     Time    Size    Name
  1     0       0       0       foo.asm

 Line Number Statements:
  [0x00000028]  Extended opcode 2: set Address to 0x401000
  [0x00000033]  Special opcode 8: advance Address by 0 to 0x401000 and Line by 3 to 4
  [0x00000034]  Special opcode 76: advance Address by 5 to 0x401005 and Line by 1 to 5
  [0x00000035]  Special opcode 76: advance Address by 5 to 0x40100a and Line by 1 to 6
  [0x00000036]  Advance PC by 2 to 0x40100c
  [0x00000038]  Extended opcode 1: End of Sequence

Ubuntu 22.04，NASM 2.15.05，GDB 12.09

Answer 1

我设置了Ubuntu 22.04 VM，发现我可以复制您在那里看到的问题，但是，在本地机器上，我无法再现问题。

我注意到在本地机器上，我使用的是NASM 2.14.02，而在Ubuntu机器上，我使用的是2.15.05。

如果我们在两个可执行文件上检查 objdump -g 输出，这是我从工作可执行文件中看到的部分：

Contents of the .debug_info section (loaded from foo):

  Compilation Unit @ offset 0x0:
   Length:        0x45 (32-bit)
   Version:       3
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_low_pc      : 0x401000
    <14>   DW_AT_high_pc     : 0x40100c
    <1c>   DW_AT_stmt_list   : 0x0
    <20>   DW_AT_name        : foo.asm
    <28>   DW_AT_producer    : NASM 2.14.02
    <35>   DW_AT_language    : 32769    (MIPS assembler)
 <1><37>: Abbrev Number: 2 (DW_TAG_subprogram)
    <38>   DW_AT_low_pc      : 0x401000
    <40>   DW_AT_frame_base  : 0x0 (location list)
 <1><44>: Abbrev Number: 0

这是损坏的可执行文件中的相同部分：

Contents of the .debug_info section (loaded from foo):

  Compilation Unit @ offset 0x0:
   Length:        0x45 (32-bit)
   Version:       3
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_low_pc      : 0x401000
    <14>   DW_AT_high_pc     : 0x401000
    <1c>   DW_AT_stmt_list   : 0x0
    <20>   DW_AT_name        : foo.asm
    <28>   DW_AT_producer    : NASM 2.15.05
    <35>   DW_AT_language    : 32769    (MIPS assembler)
 <1><37>: Abbrev Number: 2 (DW_TAG_subprogram)
    <38>   DW_AT_low_pc      : 0x401000
    <40>   DW_AT_frame_base  : 0x0 (location list)
 <1><44>: Abbrev Number: 0

关键区别是 dw_at_high_igh_igh_pc ，这似乎是2.15.05 NASM的错误。我手动进入并编辑了这个值，突然之间，我可以很好地调试以前破碎的可执行文件。

这似乎是NASM的2.15.05中的回归，您应该考虑降低NASM（我认为2.15.05是当前的最新版本），或者也许会提交NASM错误。

Answer 2

在Debug-Info一代中有一个长期存在的NASM错误，并固定在2.16中。从

• 修复了小矮人调试格式的代码范围生成错误（ dw_at_high_pc 字段中的不正确信息）针对小精灵输出格式进行了修复。 此错误碰巧在GNU Binutils Linker的较旧版本中取消了一个错误，但是与其他链接和更新的链接或其他期望遵循规格的链接器中断。

---

旧答案：调试机器代码，忘记源。或使用Stabs

IIRC，GDB可以与NASM的默认刺伤输出一起使用，因此，它使用它而不是矮人。 Jester说，GNU工具使用了NASM不知道如何制作的较新的矮人格式。但是他们仍然支持矮人更换的刺伤格式。对于将源线映射到地址的简单任务来说，刺伤是不错的，这就是简单的源语言之类的简单源语言所需的一切。

只需使用 nasm -g 没有 -f 选项。

或忽略 -g ：您仍然会得到符号名称，而且我从未在基本标签名称之外用手编写的ASM中的调试信息有太多用途。 （当然还有截面标题，在可执行文件中也不需要，只有程序标题

---

。 >布局n 布局reg ，切换到寄存器 +拆卸。曾经是布局reg reg wes as;我不确定当前行为是GDB错误还是什么。 （在某些以前的版本中，这两个布局next / prev 都需要，就像认为配置设置与UI实际显示的内容是不同步的）。

无论如何，我基本上永远都不希望GDB显示 .asm 源，我希望它显示出我运行的任何内容的规范拆卸，以防我写的东西与外观不同。

在您的ASM源中使用有意义的标签名称将导致GDB在 sieve.crossout 或其他任何内容中显示执行。尽管在有条件的分支方面不太好，但由于每个分支目标看起来都是GDB的完整标签。

Answer 3

我也有相同的情况“单步进，直到从功能主管中退出，该函数没有线编号信息。”我检查了GCC和GDB版本，但需要记住NASM。
我在2.15.05版本中有这个问题。因此，我将NASM升级为2.16.01版本，没关系。

Answer 4

正如安德鲁（Andrew）所指出的那样，这确实是nasm中的一个错误（ https：//bugzilla.nasm.nasm. us/show_bug.cgi？id = 3392798 ）。它不会通过降级来修复，因为从我的理解来看，该错误很旧。

该错误目前是普及的，因为旧版本的GNU LD有一个与此相辅相成的问题（使其无法察觉）。 LLD和Gold的Afaik使用者很久以前就经历了这个问题。

不错的部分是我发送了一个非常简单而又小的补丁（并且在阅读LD-nasm互动以及为什么以前没有发现后，我感到很自在的想法是正确的）。

如果您倾向于阅读补丁程序（如果您发现问题，甚至可能会留下有用的评论），它在这里： https://github.com/netwide-sembler/nasm/pull/35

另外，如果您使用ubuntu 22.04，我构建了一个修补的.deb，应该相对容易安装。