Почему коды операций, которые я получаю с помощью NASM, не могут быть правильно выполнены процессором Bochs i386?

Абстрактный:

Я обнаружил, что многие форматы вывода, поддерживаемые NASM, генерируют очень разреженный машинный код с чередованием нулей. Самое главное, они не могут быть правильно поняты процессором Bochs i386.

Я считаю, что вина на мне, но не знаю, где и почему.

Мой источник:

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

Если я вывожу формат бина: 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 не поддерживает связывание)

Например, ЭЛЬФ: 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 ??

Как это выполняется процессором:

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. Или как мне настроить bochs, чтобы он мог выполнять этот код.

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

person Chiron    schedule 01.12.2016    source источник
comment
Почему две инструкции CLI?   -  person Michael Petch    schedule 01.12.2016
comment
на самом деле... я подумал, что будет проще найти начальную позицию моего кода с помощью 0xfafa @MichaelPetch   -  person Chiron    schedule 01.12.2016
comment
У вас есть директива BITS 16 в файле сборки вверху? Если вы ассемблируете в NASM с -f bin, по умолчанию используется 16-битная генерация кода. Если вы используете -f elf, он предполагает 32-битные инструкции по умолчанию. Поместите директиву BITS 16 в начало файла сборки, чтобы при использовании -f elf она по-прежнему генерировала 16-битный код. Подробнее об этом здесь: nasm.us/doc/nasmdoc7.html   -  person Michael Petch    schedule 01.12.2016
comment
Если вы действительно хотите выполнить инструкцию SSE из загрузчика, см. stackoverflow.com/questions/31563078/, чтобы узнать, как включить SSE.   -  person Peter Cordes    schedule 01.12.2016
comment
Если вы последуете моему совету по созданию 16-битного кода, приведенному выше, имейте в виду, что если вы используете OBJDUMP для 32-битного объекта или исполняемого файла, по умолчанию он будет декодировать инструкции, как если бы они были 32-битными. OBJDUMP (или любой инструмент, который декодирует elf) на самом деле не знает, что ассемблер сгенерировал 16-битный код. Чтобы обойти это, если вы хотите декодировать 16-битный код, используйте -mi8086 в качестве параметра для OBJDUMP, чтобы он выполнял правильное декодирование.   -  person Michael Petch    schedule 01.12.2016


Ответы (1)


Вкратце: потому что 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: Flat- Формирование двоичного вывода
Использование формата bin переводит NASM по умолчанию в 16-битный режим.

7.9.7 16-битный код и ELF
Спецификация ELF32 не предусматривает перемещения для 8- и 16-битных значений, но компоновщик GNU ld добавляет их в качестве расширения. NASM может генерировать GNU-совместимые релокации, чтобы 16-битный код мог быть связан как ELF с использованием GNU ld. Если NASM используется с параметром -w+gnu-elf-extensions, при создании одного из этих перемещений выдается предупреждение.

И если у вас есть BITS 16, то он генерирует 32-битный образ ELF с 16-битным кодом.

Взгляните на это:

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 гигабайт; он использует основные типы, определенные выше.
Класс ELFCLASS64 зарезервирован для 64-разрядных архитектур. Его внешний вид здесь показывает, как может измениться объектный файл, но в остальном 64-битный формат не указан. При необходимости будут определены другие классы с различными базовыми типами и размерами данных объектных файлов.

Итак, ELF не поддерживает класс 16-битного кода!

Также проверьте это https://github.com/letolabs/nasm/tree/master/output

person amaneureka    schedule 02.12.2016