Jumping into infinite loop when mapping virtual address

[iansjack]

I'm puzzled as to why you just don't use your debugger to display the register values you are interested in. It has many more facilities than you can reasonably write to display registers and memory and to trace the execution path. This is assuming you are running in a VM, rather than on bare metal, which is a sensible way to proceed at this stage.

I do wonder from your posts if you are fully comfortable with assembly language.

[NeonLightions]

Hi,

Code: Select all

0x0010363b:  89 10                    movl     %edx, (%eax)
0x0010363d:  81 fb 00 00 00 08        cmpl     $0x8000000, %ebx
0x00103643:  74 7e                    je       0x1036c3
 
Servicing hardware INT=0x20
----------------
IN: 
0x00000000:  53                       pushl    %ebx
0x00000001:  ff 00                    incl     (%eax)
0x00000003:  f0                       .byte    0xf0

Go ahead and post a similar output with what you did before. Keep hardware interrupts disabled. The code posted before triggered the timer irq right before so we want to keep that disabled. If hardware interrupts are disabled, you should be getting different output.

Hi,
here is the disassembly of kernel.bin after changing few stuff:

Code: Select all

----------------
IN: 
0x00103656:  83 c4 10                 addl     $0x10, %esp
0x00103659:  85 c0                    testl    %eax, %eax
0x0010365b:  75 c3                    jne      0x103620

----------------
IN: 
0x00103620:  8b 08                    movl     (%eax), %ecx
0x00103622:  89 da                    movl     %ebx, %edx
0x00103624:  81 c3 00 10 00 00        addl     $0x1000, %ebx
0x0010362a:  81 e2 00 f0 ff ff        andl     $0xfffff000, %edx
0x00103630:  83 ca 01                 orl      $1, %edx
0x00103633:  81 e1 f8 0f 00 00        andl     $0xff8, %ecx
0x00103639:  09 ca                    orl      %ecx, %edx
0x0010363b:  89 10                    movl     %edx, (%eax)
0x0010363d:  81 fb 00 00 00 08        cmpl     $0x8000000, %ebx
0x00103643:  74 7e                    je       0x1036c3

----------------
IN: 
0x00000000:  53                       pushl    %ebx
0x00000001:  ff 00                    incl     (%eax)
0x00000003:  f0                       .byte    0xf0
0x00000004:  53                       pushl    %ebx
0x00000005:  ff 00                    incl     (%eax)
0x00000007:  f0                       .byte    0xf0
0x00000008:  c3                       retl     

----------------
IN: 
0x00000001:  ff 00                    incl     (%eax)
0x00000003:  f0                       .byte    0xf0
0x00000004:  53                       pushl    %ebx
0x00000005:  ff 00                    incl     (%eax)
0x00000007:  f0                       .byte    0xf0
0x00000008:  c3                       retl     

[NeonLightions]

I'm puzzled as to why you just don't use your debugger to display the register values you are interested in. It has many more facilities than you can reasonably write to display registers and memory and to trace the execution path. This is assuming you are running in a VM, rather than on bare metal, which is a sensible way to proceed at this stage.

I do wonder from your posts if you are fully comfortable with assembly language.

Sorry, I'm just not used to using a debugger. But it can be a very good method in many cases later on.

[neon]

Hi,

Code: Select all

0x00103643:  74 7e                    je       0x1036c3
----------------
IN:
0x00000000:  53                       pushl    %ebx

Unfortunately what is posted above is a JMP REL8 which cannot set R/EIP to 0. I.e. it isn't a single step of the code. So I am seeing we have two options: post the disk image for others to debug or try to work out how to use the debugger to single step the code. Realistically you will have to be comfortable with the debugger to be able to proceed.

[NeonLightions]

Hi,

Code: Select all

0x00103643:  74 7e                    je       0x1036c3
----------------
IN:
0x00000000:  53                       pushl    %ebx

Unfortunately what is posted above is a JMP REL8 which cannot set R/EIP to 0. I.e. it isn't a single step of the code. So I am seeing we have two options: post the disk image for others to debug or try to work out how to use the debugger to single step the code.

Post a disk image? You mean *.iso file? In that case here you are: https://drive.google.com/file/d/1-unAJm ... sp=sharing

Realistically you will have to be comfortable with the debugger to be able to proceed.

You are right, I should get comfortable to it. Thanks for your advice

[iansjack]

Sorry, I'm just not used to using a debugger. But it can be a very good method in many cases later on.

Well, now would be a very good time to learn how to use your debugger. It will save you many sleepless nights.

[NeonLightions]

Sorry, I'm just not used to using a debugger. But it can be a very good method in many cases later on.

Well, now would be a very good time to learn how to use your debugger. It will save you many sleepless nights.

Hi,
After using gdb, i realized: I can't use

Code: Select all

target record

or

Code: Select all

target record-full

in host system's GDB. I have searched wiki but no information about how to install i686-elf-gdb. Do you have any suggestion?

[iansjack]

You shouldn't need to use either of those commands in your current situation. (And gdb is gdb - there's no i686-elf-gdb- though you may - eventually - want to port gdb to your operating system.)

All you need to use are judiciously placed breakpoints single-stepping, and the instructions to inspect registers and memory. (Watches are also useful in certain situations.)

[neon]

Hi,

The last address _kalloc_temp() return is: 0010A000

You are overwriting the stack with the memset. Be more careful with where things are in memory and the system memory map. At address 0:

Code: Select all

<bochs:7> print-stack 40
Stack address size 4
 | STACK 0x0010af68 [0x00000000]
*snip all 0's here*
 | STACK 0x0010afa4 [0x00000000]
 | STACK 0x0010afa8 [0x00000000] <-- compare with below
 | STACK 0x0010afac [0x00000000]
 | STACK 0x0010afb0 [0x00000000]
*snip a lot of 0's here*

Start of loop:

Code: Select all

<bochs:6> print-stack
Stack address size 4
 | STACK 0x0010afa8 [0x00000000]
 | STACK 0x0010afac [0x2badb002]
 | STACK 0x0010afb0 [0x0010afd0]
 | STACK 0x0010afb4 [0x00800000]
 | STACK 0x0010afb8 [0x00000000]
 | STACK 0x0010afbc [0x00000000]
 | STACK 0x0010afc0 [0x0010afd0]

[NeonLightions]

Hi,

The last address _kalloc_temp() return is: 0010A000

You are overwriting the stack with the memset. Be more careful with where things are in memory and the system memory map. At address 0:

Code: Select all

<bochs:7> print-stack 40
Stack address size 4
 | STACK 0x0010af68 [0x00000000]
*snip all 0's here*
 | STACK 0x0010afa4 [0x00000000]
 | STACK 0x0010afa8 [0x00000000] <-- compare with below
 | STACK 0x0010afac [0x00000000]
 | STACK 0x0010afb0 [0x00000000]
*snip a lot of 0's here*

Start of loop:

Code: Select all

<bochs:6> print-stack
Stack address size 4
 | STACK 0x0010afa8 [0x00000000]
 | STACK 0x0010afac [0x2badb002]
 | STACK 0x0010afb0 [0x0010afd0]
 | STACK 0x0010afb4 [0x00800000]
 | STACK 0x0010afb8 [0x00000000]
 | STACK 0x0010afbc [0x00000000]
 | STACK 0x0010afc0 [0x0010afd0]

What should I do? Should I remove memset()?

[Octocontrabass]

Your heap overlaps your stack. You need to adjust where everything will be located in memory so that there are no overlaps.

[NeonLightions]

Your heap overlaps your stack. You need to adjust where everything will be located in memory so that there are no overlaps.

So I have to edit linker.ld to get them no overlap? How should I do to get that?

[neon]

Hi,

Sure if you think that'll work. Just have to make sure they don't overlap is all. Either move the heap somewhere else or move the stack somewhere else. Do not remove memset as it would obfuscate it (would break in unexpected ways.) This is dependent on your design here -- i.e. i dont use a linker map. But that doesnt matter as you already know where at in your code and how the stack and heap are set up so you would be the best one to determine how and what needs to be updated.

[NeonLightions]

Hi,
Thank you everyone for helping me, . I have fixed it by add this to my linker.ld:

Code: Select all

/**
 * Kernel basic linker script, following the OSDev wiki on
 * https://wiki.osdev.org/Bare_Bones.
 */
OUTPUT_FORMAT("elf32-i386")

/** Starts execution at the '_start' symbol as defined in `boot.s`. */
ENTRY(_start)


/** Sections layout. */
SECTIONS
{
    /**
     * Kernel's booting code will be loaded starting at 1MiB address by the
     * bootloader by convention.
     */
    . = 1M;

    .text BLOCK(4K) : ALIGN(4K)    /** Align to 4KiB boundary. */
    {
        KEEP(*(.multiboot))     /** Put multiboot header before code. */
        *(.text)
        *(.comment)
    }

    .rodata BLOCK(4K) : ALIGN(4K)
    {
        *(.rodata)
    }

    .data BLOCK(4K) : ALIGN(4K)
    {
        *(.data)
    }

    .bss BLOCK(4K) : ALIGN(4K)
    {
        *(COMMON)
        *(.bss)     /** Includes our 16KiB temporary stack. */
    }

    place_to_put_heap = .;   <---- New line
}

... and export it to my C code. I'm not use elf_shstrtab_end, I use place_to_put_heap instead like this:

Code: Select all

// Somewhere in paging.c
extern uint32_t place_to_put_heap;

// In paging.c->paging_init()
kheap_curr = ADDR_PAGE_ROUND_UP((uint32_t) &place_to_put_heap);

Again, thank you everyone for help me to fix this issue!