binary format vs elf64 format

[citop]

Single-step the code under a debugger to see what is going wrong.

unfortunately gdb server is not functioning normal with qemu, so i have not found out a way to do single step debugging

[iansjack]

Try SimNow ( http://developer.amd.com/tools-and-sdks ... simulator/ ). It is a very good tool for debugging assembler programs. But when you get serious and start using C you'll need to sort out your gdb problem.

[Schol-R-LEA]

You could also use Bochs, which has a built-in debugger that can be single-stepped; however, you would need a version of it built with the debugger option, and the standard builds that are distributed for Windows, MacOS, and most Linux package managers don't have that as the default, so you may need to build the Bochs executable yourself.

[citop]

Now I think the most possible problem may be in the elf loader, because I did the app test at the kernel entry point right after boot loader passed over control to kernel, and the problem occurred. But the elf loader seemed so straight forward, really can't identify what's wrong

[iansjack]

This is why you need to do some debugging.

[citop]

I added below testing to both boot loader(right before jumping to kernel), and to the kernel(right after get control from boot loader)

Code: Select all

simuapp_run:
        mov rax, 0x0000c300001234b8 ; machine code for:  mov rax 0x1234 + ret
        mov rdi, 0x0000000000800000
        stosq
        call 0x0000000000800000
        ret

the boot loader is okay to call the test procedure, but the kernel got GP exception, with RIP = 0.
that's really strange. the only difference is that the loader is in raw bin format, while the kernel is in elf64 format. does elf64 has any affect on memory protection attributes?

[iansjack]

The elf format is just that - a file format. It only affects anything in the way that you interpret it.

Last time I'll say this: use a debugger to inspect the program.

[MichaelFarthing]

I added below testing to both boot loader(right before jumping to kernel), and to the kernel(right after get control from boot loader)

Code: Select all

simuapp_run:
        mov rax, 0x0000c300001234b8 ; machine code for:  mov rax 0x1234 + ret
        mov rdi, 0x0000000000800000
        stosq
        call 0x0000000000800000
        ret

the boot loader is okay to call the test procedure, but the kernel got GP exception, with RIP = 0.
that's really strange. the only difference is that the loader is in raw bin format, while the kernel is in elf64 format. does elf64 has any affect on memory protection attributes?

You presumably mean machine code for: mov eax 0x1234 ret
Not sure of your set up, and my 64 bit knowledge is rudimentary, but could it be that the boot loader is defaulting to 32 bit register size and the kernel to 64, so the boot is seeing the line above and the kernel is seeing mov rax 0xc300001234

[citop]

I added below testing to both boot loader(right before jumping to kernel), and to the kernel(right after get control from boot loader)

Code: Select all

simuapp_run:
        mov rax, 0x0000c300001234b8 ; machine code for:  mov rax 0x1234 + ret
        mov rdi, 0x0000000000800000
        stosq
        call 0x0000000000800000
        ret

the boot loader is okay to call the test procedure, but the kernel got GP exception, with RIP = 0.
that's really strange. the only difference is that the loader is in raw bin format, while the kernel is in elf64 format. does elf64 has any affect on memory protection attributes?

You presumably mean machine code for: mov eax 0x1234 ret
Not sure of your set up, and my 64 bit knowledge is rudimentary, but could it be that the boot loader is defaulting to 32 bit register size and the kernel to 64, so the boot is seeing the line above and the kernel is seeing mov rax 0xc300001234

not presumably. the machine code is generated by compiling the below source with nasm:

Code: Select all

        USE64
                 mov rax, 0x1234
                 ret

what's more, if the kernel is in raw binary format, then everything is OK.