guest VM (vbox) not interpreting the call address right

[juryduty000]

I got rather complicate task of building C and asm code together and from the mbr jump to C code directly. Both built with nasm and gcc with 32-bit switch to get it right. But when it calls asm function from C (main) it interprets the called function's address exactly 2 bytes less. Closer look reveals VM guest is interpreting the opcode differently for call:

opcode on vm shows:

Code: Select all

0800:0000001f e8 48 00                call 0006ah  <-
0800:00000022 00 00                   add byte [bx+si], al

Code: Select all

opcode on objdump shows: e8 48 00 00 00
1f: e8 48 00 00 00                call   0x6c

What do I make of this? I know this is bit of a hacky way because I generated the elf binary, truncated the header + plus all the code till the beginning of main() and just mbr code directly jumped into the main() (below address 0-1f). I see there are some codes functions being called before calling function at 6c, so not sure it has anything to do with above address interpretation:

Code: Select all

Disassembly of section .data:

0 <.data>:
       0:       8d 4c 24 04             lea    0x4(%esp),%ecx
       4:       83 e4 f0                and    $0xf0,%esp
       7:       ff 71 fc                pushl  -0x4(%ecx)
       a:       55                      push   %ebp
       b:       89 e5                   mov    %esp,%ebp
       d:       53                      push   %ebx
       e:       51                      push   %ecx
       f:       e8 ef fe ff ff          call   0xffffff03
      14:       81 c3 db 1a 00 00       add    $0x1adb,%ebx
      1a:       83 ec 0c                sub    $0xc,%esp
      1d:       6a 5b                   push   $0x5b
      1f:       e8 48 00 00 00          call   0x6c
      24:       83 c4 10                add    $0x10,%esp
      27:       83 ec 04                sub    $0x4,%esp
      2a:       6a f9                   push   $0xf9

[nexos]

Are you saying that you are trying to use C code in the MBR? If so, that is not how you should do it. You should write the whole thing in asm. Also, you can tell ld to make a pure binary file by using the OUTPUT_FORMAT(binary) command in your ld script. Anyway, it looks a little strange how it shows it in the .data section. Is that intentional? Plus, notice how in the objdump output, the call 0x6c is not call $0x6c, which means it is reading what is at the address 0x6c and using that for the call instruction.
Hope this helps,
nexos

[Octocontrabass]

opcode on vm shows:

It shows the code disassembled as 16-bit, but your objdump output shows 32-bit code. Are you trying to execute 32-bit code in 16-bit mode?

I know this is bit of a hacky way because I generated the elf binary, truncated the header + plus all the code till the beginning of main() and just mbr code directly jumped into the main() (below address 0-1f).

You can make it less of a hack by using objdump to convert the ELF binary into a flat binary. (A bootloader that handles ELF binaries would be even better.)

Is there any particular reason you have to write a bootloader? Writing a bootloader that works well across a wide variety of hardware can be surprisingly difficult.