Why the opcodes I get using NASM can't be executed correctly by bochs i386 CPU?

Question

Abstract:

I found many output formats supported in NASM generate very sparse machine-code interlaced with 0s. Most importantly, they can't be correctly understood by bochs' i386 cpu.

I believe the fault is on myself, but don't know where and why.

My source:

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

If I output "bin" format: 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

It looks pretty compact, good! It can be executed correctly.

That's what NASM thinks what it should generate for this bin format:

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

Good! That's what I want!

But When I generate other types (because bin doesn't support linking)

For example, 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

What NASM thinks it should generate:

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 ??

How It is executed by 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

Furthermore, if I generate other output formats like Mach-O or 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

Still wrong.

How can I make things right and generates codes that can be correctly executed by bochs i386 cpu. Or how can I tune bochs so that it can execute that code.

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

actually....I thought it would be easier to locate the start position of my code by "0xfafa" @MichaelPetch — Chiron, Dec 01 '16 at 04:23
Do you have a `BITS 16` directive in your assembly file at the top? If you assemble in NASM with `-f bin` it defaults to 16 bit code generation. If you use `-f elf` it assumes 32-bit instructions as default. Place a `BITS 16` directive at the top of your assembly file so that when `-f elf` is used it will still generate 16-bit code. More info on this here: http://www.nasm.us/doc/nasmdoc7.html — Michael Petch, Dec 01 '16 at 04:24
If you want to actually execute SSE instruction from a bootloader, see http://stackoverflow.com/questions/31563078/how-do-i-enable-sse-for-my-freestanding-bootable-code for how to enable SSE. — Peter Cordes, Dec 01 '16 at 04:35
If you take my advice about generating 16 bit code above, be aware that if you use OBJDUMP on a 32-bit object or executable, by default it will decode the instructions as if they were 32-bit. OBJDUMP (or any tool that decodes elf) doesn't actually know the assembler generated 16-bit code. To get around this, if you want to decode 16-bit code use `-mi8086` as a parameter to OBJDUMP so that it does proper decoding. — Michael Petch, Dec 01 '16 at 05:30

amaneureka · Accepted Answer · 2016-12-02T07:29:50.267

In short: Because ELF does not support 16-bit code class.

Long answer: oh, that's because NAsm generated a 32-bit elf image.

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-Form Binary Output
Using the bin format puts NASM by default into 16-bit mode.

7.9.7 16-bit code and ELF
The ELF32 specification doesn't provide relocations for 8- and 16-bit values, but the GNU ld linker adds these as an extension. NASM can generate GNU-compatible relocations, to allow 16-bit code to be linked as ELF using GNU ld. If NASM is used with the -w+gnu-elf-extensions option, a warning is issued when one of these relocations is generated.

And if you have BITS 16 then it generates 32-bit ELF image with 16-bit Code.

Take a look at this:

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

But format is still elf32-i386. Now question is why? Let's take a look at ELF documentation

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

EI_CLASS The next byte, e_ident[EI_CLASS], identifies the file’s class, or capacity.
The file format is designed to be portable among machines of various sizes, without imposing the sizes of the largest machine on the smallest. Class ELFCLASS32 supports machines with files and virtual address spaces up to 4 gigabytes; it uses the basic types defined above.
Class ELFCLASS64 is reserved for 64-bit architectures. Its appearance here shows how the object file may change, but the 64-bit format is otherwise unspecified. Other classes will be defined as necessary, with different basic types and sizes for object file data

So, ELF Does not support 16-Bit Code class!

Also check this https://github.com/letolabs/nasm/tree/master/output

Why the opcodes I get using NASM can't be executed correctly by bochs i386 CPU?

1 Answers1