3

抽象的：

我发现 NASM 中支持的许多输出格式会生成非常稀疏的机器代码，并与 0 交错。最重要的是，bochs 的 i386 cpu 无法正确理解它们。

我相信错在我自己，但不知道在哪里以及为什么。

我的来源：

cli
cli
mov ax,cs
mov ds,ax
mov es,ax
call ClearTty        <- here
call ResetCursor     <- here
mov al,43h ;'C'
call DispAL
jmp $
...

如果我输出“bin”格式：nasm -f bin boot.s -o boot.o

bin: 
fafa 8cc8 8ed8 8ec0 e80a 00e8 2500 b043  <- No 0000 filled, GOOD
e838 00eb feb0 0066 5566 5450 5152 b406  <- No 0000 filled, GOOD
b900 008a 3685 00b2 50cd 105a 5958 665c
665d c3ba 0000 6655 6654 5053 b402 b700
cd10 5b58 665c 665d c3b0 4166 5566 5450
5351 b409 b700 b30f b901 00cd 1059 5b58
665c 665d c350 80fa 5072 07b2 00fe c6e9
0200 fec2 3a36 8500 7609 b001 e898 ff8a

看起来很紧凑，不错！它可以正确执行。

这就是 NASM 认为应该为这种 bin 格式生成的内容：

compile to bin
ADDRESS  OPCODES                 DISASM
00000000 FA                      cli
00000001 FA                      cli
00000002 8CC8                    mov ax,cs
00000004 8ED8                    mov ds,ax
00000006 8EC0                    mov es,ax                                     
00000008 E80A00                  call ClearS        <- GOOD
0000000B E82500                  call ResetCursor   <- GOOD

好的！这就是我想要的！

但是当我生成其他类型时（因为 bin 不支持链接）

例如，ELF：nasm -f elf boot.s -o boot.o

[boot.elf: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped]
elf 352-bytes-header omitted
fafa 668c c88e d88e c0e8 0e00 0000 e82c  <- 0000 WHY????
0000 00b0 43e8 3e00 0000 ebfe b000 5554  <- 0000 WHY????
6650 6651 6652 b406 66b9 0000 8a35 9f00
0000 b250 cd10 665a 6659 6658 5c5d c366
ba00 0055 5466 5066 53b4 02b7 00cd 1066
5b66 585c 5dc3 b041 5554 6650 6653 6651
b409 b700 b30f 66b9 0100 cd10 6659 665b

NASM 认为它应该产生什么：

compile to elf  
00000000 FA                      cli
00000001 FA                      cli
00000002 668CC8                  mov ax,cs
00000005 8ED8                    mov ds,ax
00000007 8EC0                    mov es,ax
                                 
00000009 E80E000000              call ClearS         <- Very long code ??
0000000E E82C000000              call ResetCursor    <- Very long code ??

cpu是如何执行的：

00007eb0: cli                       ; fa
00007eb1: cli                       ; fa
00007eb2: mov ax, cs                ; 668cc8
00007eb5: mov ds, ax                ; 8ed8
00007eb7: mov es, ax                ; 8ec0
00007eb9: call .+14                 ; e80e00
00007ebc: add byte ptr ds:[bx+si], al ; 0000  WRONG!!! What is that? 
00007ebe: call .+44                 ; e82c00
00007ec1: add byte ptr ds:[bx+si], al ; 0000  WRONG!!!
00007ec3: mov al, 0x43              ; b043
00007ec5: call .+62                 ; e83e00
00007ec8: add byte ptr ds:[bx+si], al ; 0000  WRONG!!!
00007eca: jmp .-2                   ; ebfe

此外，如果我生成其他输出格式，如 Mach-O 或 Obj：

compile to other e.g. MachO [boot.o: Mach-O object i386]

00000000 FA                      cli
00000001 FA                      cli
00000002 668CC8                  mov ax,cs
00000005 8ED8                    mov ds,ax
00000007 8EC0                    mov es,ax                                     
00000009 E80E000000              call ClearS        <- Still so long
0000000E E82C000000              call ResetCursor   <- Still so long

还是错了。

我怎样才能使事情正确并生成可以由 bochs i386 cpu 正确执行的代码。或者我如何调整 bochs 以便它可以执行该代码。

 my bochsrc: cpuid: level=6, mmx=1, apic=xapic, sep=1, aes=1, movbe=1,
 simd=ssse3, misaligned_sse=1
4

1 回答 1

2

简而言之：因为 ELF 不支持 16 位代码类。

长答案： 哦，那是因为 NAsm 生成了 32 位精灵图像。

F:\dev>objdump -D test

test:     file format elf32-i386


Disassembly of section .text:

00000000 <ClearTty-0x13>:
   0:   fa                      cli
   1:   fa                      cli
   2:   66 8c c8                mov    %cs,%ax
   5:   8e d8                   mov    %eax,%ds
   7:   8e c0                   mov    %eax,%es
   9:   e8 05 00 00 00          call   13 <ClearTty>
   e:   e8 01 00 00 00          call   14 <ResetCursor>

00000013 <ClearTty>:
  13:   c3                      ret

00000014 <ResetCursor>:
  14:   f4                      hlt

6.1 bin：平面二进制输出
使用 bin 格式将 NASM 默认设置为 16 位模式。

7.9.7 16 位代码和 ELF
ELF32 规范不提供 8 位和 16 位值的重定位，但 GNU ld 链接器将这些作为扩展添加。NASM 可以生成与 GNU 兼容的重定位，以允许使用 GNU ld 将 16 位代码链接为 ELF。如果 NASM 与 -w+gnu-elf-extensions 选项一起使用，则在生成这些重定位之一时会发出警告。

如果你有，BITS 16那么它会生成带有 16 位代码的 32 位 ELF 图像。

看看这个：

test:     file format elf32-i386


Disassembly of section .text:

00000000 <ClearTty-0xe>:
   0:   fa                      cli
   1:   fa                      cli
   2:   8c c8                   mov    %cs,%eax
   4:   8e d8                   mov    %eax,%ds
   6:   8e c0                   mov    %eax,%es
   8:   e8 03 00 e8 01          call   1e80010 <ResetCursor+0x1e80001>
   ; e8 03 00 e8 01 should be e8 03 00 and e8 01 00 <-- two call instructions

但格式仍然是elf32-i386。现在的问题是为什么？让我们看一下ELF文档

http://www.skyfree.org/linux/references/ELF_Format.pdf

EI_CLASS下一个字节 ,e_ident[EI_CLASS]标识文件的类或容量。
该文件格式旨在在各种大小的机器之间移植，而不会将最大机器的大小强加于最小机器。类ELFCLASS32支持文件和虚拟地址空间高达 4 GB 的机器；它使用上面定义的基本类型。
类ELFCLASS64是为 64 位架构保留的。它在此处的出现显示了目标文件可能如何更改，但 64 位格式未指定。其他类将根据需要定义，对象文件数据具有不同的基本类型和大小

所以，ELF 不支持 16-Bit Code 类！

还要检查这个https://github.com/letolabs/nasm/tree/master/output

于 2016-12-02T07:06:30.680 回答