Why is multiboot information corrupted when passing to func?

[mrjbom]

Hello.
This problem is probably not entirely related to the development of the OS, but it is PROBABLY not a bug in the code.
I think my problem is related to some sort of misunderstanding when working with memory.

I get a pointer to a multiboot structure and pass it to a function that copies that pointer and then uses the address of the graphics buffer to draw on the screen.

In kernel.c is connected header.h, which has a pointer to multiboot information and a function that copies it and paints over the screen

kernel.c

Code: Select all

#include "kernel.h"

int main(unsigned long magic, multiboot_info_t* mbi)
{
    (void)magic;
    initMultibootInfo(mbi);
}

header.h

Code: Select all

multiboot_info_t* MBI;

void initMultibootInfo(multiboot_info_t* mbiTemp)
{
    MBI = mbiTemp;
    volatile uint32_t *fb = (uint32_t *)((uint32_t) MBI->framebuffer_addr);
    uint32_t cell;

    for (cell = 0; cell < MBI->framebuffer_width * MBI->framebuffer_height; cell++)
        fb[cell] = 0x00FE01AC;
}

If I use MBI in the code - nothing works.
And if I use mbiTemp - everything works.

It turns out because of a simple copy of the pointer-nothing works.

[Octocontrabass]

How are you compiling and linking your code into your kernel binary?

[mrjbom]

How are you compiling and linking your code into your kernel binary?

I collect image so:


nasm -f elf32 ./source/kernel.asm -o kasm.o
gcc -m32 ./source/kernel.c -o kc.o
ld -m elf_i386 -T link.ld -o kernel-0 kasm.o kc.o


I have no idea why copying a pointer leads to such consequences, the code is correct and everything should be fine.
The pointer is damaged as if by itself.

[Octocontrabass]

Why aren't you using a cross-compiler? Using one is strongly recommended, since it gives you a consistent development environment that anyone can duplicate

Do you have an online repository somewhere so we can see all of your code? I'm particularly interested in your linker script and your stack setup.

[MichaelPetch]

Can you show how you define and set your stack (ESP)? Almost wonder if you set it up wrong and the stack is overwriting the BSS section where MBI may reside. Almost wondering if you set the stack to grow down from the beginning of stack memory and not the end.

[mrjbom]

Why aren't you using a cross-compiler? Using one is strongly recommended, since it gives you a consistent development environment that anyone can duplicate

Isn't gcc a cross compiler?

Do you have an online repository somewhere so we can see all of your code? I'm particularly interested in your linker script and your stack setup.

linker script

Code: Select all

/*
*  link.ld
*/
OUTPUT_FORMAT(elf32-i386)
ENTRY(start)
SECTIONS
 {
   . = 0x100000;
   .text : { *(.text) }
   .data : { *(.data) }
   .bss  : { *(.bss)  }
 }

Set up a stack? I didn't set up anything and I don't know what you're talking about. This may be the cause of the problem. What's it?

[MichaelPetch]

Just show us kernel.asm . If you haven't set ESP (Stack pointer) that may be the cause of issues.

[mrjbom]

Just show us kernel.asm . If you haven't set ESP (Stack pointer) that may be the cause of issues.

kernel.asm

Code: Select all

bits 32

%define MULTIBOOT_MAGIC 0x1BADB002
%define MULTIBOOT_FLAGS (1<<0 | 1<<1 | 1<<2)

section .text
align 4
multiboot_header:
    dd MULTIBOOT_MAGIC
    dd MULTIBOOT_FLAGS
    dd -(MULTIBOOT_MAGIC + MULTIBOOT_FLAGS)
    dd 0
    dd 0
    dd 0
    dd 0
    dd 0
    dd 0
    dd 800 ; width
    dd 600 ; height
    dd 32 ; bbp

global start
extern main

start:
  cli
  mov esp, stack_space
  push ebx
  push eax
  call main
  hlt

section .bss
resb 8192
stack_space:

[Octocontrabass]

Isn't gcc a cross compiler?

Not when it's called "gcc". You should be using something like "i686-elf-gcc". If you don't already have it, you can build it yourself by following these instructions.

I don't think it's the cause of your problem, but your linker script is missing the rodata section. You can see an example linker script here that might help.

[MichaelPetch]

What if you add `-ffreestanding` option to your GCC options, and then if that doesn't work rename main to kmain (in addition to using -ffreestanding).

[iansjack]

I'm not convinced that you are showing us the exact code and the exact instructions that you are using. (For example, you include a header file that we can't see, and you don't include a header file that we can see. Also the gcc instruction that you say you are using would result in an error.)

If you could link to a repository of all your code then it would be easier to try compiling it to see where the error is.

As an aside, I wouldn't include the definition of a function in a header file.

[mrjbom]

I'm not convinced that you are showing us the exact code and the exact instructions that you are using. (For example, you include a header file that we can't see, and you don't include a header file that we can see. Also the gcc instruction that you say you are using would result in an error.)

If you could link to a repository of all your code then it would be easier to try compiling it to see where the error is.

As an aside, I wouldn't include the definition of a function in a header file.

Here is a link to the repository with the source files.
I think you'll be able to compile all this and have a look.

[iansjack]

Well, I'm at a loss.

I downloaded your code and compiled it (with a little bit of extra work), and it works fine.

But it didn't compile first time because of an error with your gcc command. You need to add the -c switch to it so that it produces a simple object file. Otherwise it will try and link the program. I'm not sure why it works for you, but this may explain your strange result.

I'll repeat what I said about header files. Other than very simple functions, it is best to keep them just for declarations and to put function definitions in separate .c files.

[mrjbom]

Well, I'm at a loss.

I downloaded your code and compiled it (with a little bit of extra work), and it works fine.

But it didn't compile first time because of an error with your gcc command. You need to add the -c switch to it so that it produces a simple object file. Otherwise it will try and link the program. I'm not sure why it works for you, but this may explain your strange result.

I'll repeat what I said about header files. Other than very simple functions, it is best to keep them just for declarations and to put function definitions in separate .c files.

It's funny. I recompiled the same code on a new virtual machine and everything worked, I have no idea what it was.

Thank you for saying that everything works for you, otherwise I would be looking for a non-existent problem in the code or compilation.