Why is multiboot information corrupted when passing to func?

mrjbom · **Joined:** Sun Jul 21, 2019 7:34 am **Posts:** 300

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:

#include "kernel.h"

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

header.h

Code:

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5137

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

mrjbom · **Joined:** Sun Jul 21, 2019 7:34 am **Posts:** 300

Octocontrabass wrote:

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5137

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 · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 692

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 · **Joined:** Sun Jul 21, 2019 7:34 am **Posts:** 300

Octocontrabass wrote:

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?

Octocontrabass wrote:

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:

/*
*  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 · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 692

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

mrjbom · **Joined:** Sun Jul 21, 2019 7:34 am **Posts:** 300

MichaelPetch wrote:

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

kernel.asm

Code:

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5137

mrjbom wrote:

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 · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 692

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 · **Posted:** Wed Oct 16, 2019 8:21 am

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 · **Joined:** Sun Jul 21, 2019 7:34 am **Posts:** 300

iansjack wrote:

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 · **Posted:** Wed Oct 16, 2019 12:51 pm

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 · **Joined:** Sun Jul 21, 2019 7:34 am **Posts:** 300

iansjack wrote:

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.

OSDev.org

Why is multiboot information corrupted when passing to func?

Who is online