Variable is not changed after an assignment

[zungnguyen]

Hi all,

I am writing an OS for learning purpose
I have an issue when making an assignment in C++. The code is below

void* MemoryManager::makeMemoryEntry(void* prevAddress, uint16 size) {
Printer::printlnAddress((uint64)this);
MemoryEntry *prev = (MemoryEntry*)prevAddress;
MemoryEntry *entry;
void* entryAddress = prevAddress + sizeof(MemoryEntry) + prev->size;
entry = (MemoryEntry*)entryAddress;
entry->size = size;
entry->next = prev->next;
if (entry->next != prev->next) {
Printer::println("W T F",5);
}
uint64 *next = (uint64*)entryAddress;
prev->next = entry;
return entry;
}

In the assignment "entry->next = prev->next;". It does not work, entry->next keep the old value. Here is the source code https://github.com/nguyenzung/kos/blob/ ... anager.cpp
Many thanks

[Octocontrabass]

What are the values of prevAddress and entryAddress? Are those addresses marked as usable memory in your memory map?

[zungnguyen]

What are the values of prevAddress and entryAddress? Are those addresses marked as usable memory in your memory map?

They are stored on heap space. Their value is set correctly. entryAddress is address of the memory that the OS provide when user call malloc, prevAddress is provided chuck that will point to the entryAddress. And it is in range of the memory map. I created 64MB for initialized.
I found another situation. In my construct. I can set the variable if changing the code from " first = (MemoryEntry*) this->makeFirstMemoryEntry(0xffff);" to " first = (MemoryEntry*) this->makeFirstMemoryEntry(0xafff);". If the value is less than 0xafff. The stuff works correctly

I also turn off the interrupt handler to make sure there is only this function is running.

MemoryManager::MemoryManager() {
kernelHeapAddress = heapBase;
kernelStackBase = stackBase;
Printer::printlnAddress((uint64)kernelHeapAddress);
first = (MemoryEntry*) this->makeFirstMemoryEntry(0xffff);
MemoryManager::setInstance(this);
}

[Octocontrabass]

They are stored on heap space.

What range of addresses is your heap space?

Their value is set correctly.

What values specifically?

And it is in range of the memory map.

Can I see your memory map?

[zungnguyen]

What range of addresses is your heap space?

My heap space start at: 0x93000
My stack top at 0x4093000
I define like that [Heap] -> My running OS <- [stack top]. There are 64M for my OS running.

section .bss
global stack_base
global heap_base
heap_base: resb 64*1024*1024
stack_base:
stack_size equ $ - heap_base

What values specifically?

The prevAddress is 0xA3009
The entryAddress is 0xB3012. I expect the entryAddress should be 0xA3009 + sizeof(MemoryEntry) + allocated size of prev, should be 0xA3009 + 10 + 6
Maybe the entryAddress is protected by another stuff, so that i cannot change the value.

And it is in range of the memory map.

Can I see your memory map?

Here my mapping code: https://github.com/nguyenzung/kos/blob/ ... ctedMode.s
I index for around 256MB

I found that in linker script, my old code is:

ENTRY(start)
SECTIONS
{
. = 50000;
.text : { KEEP(*(.multiboot)) *(.text) }
.data : { *(.rodata*) *(.data*) KEEP(*(.init_array))}
.bss : { *(.bss) }
}

If i change to:

ENTRY(start)
SECTIONS
{
. = 1M;
.text : { KEEP(*(.multiboot)) *(.text) }
.data : { *(.rodata*) *(.data*) KEEP(*(.init_array))}
.bss : { *(.bss) }
}

It seems now work correctly. But i am not sure about the root cause.

[Gigasoft]

You are mapping addresses 0 to 0x200000 to the first two megabytes of the physical address space. So, for example, virtual address 0xa3009 gets translated as physical address 0xa3009, which is of course not what you want, as it does not even point to system memory. You need to set up a mapping from the executable's linked address to the address where it actually resides in memory.

[Octocontrabass]

But i am not sure about the root cause.

There was no RAM at the addresses you were trying to use.

GRUB provides a memory map. You need to use that memory map to find available RAM.

[zungnguyen]

You are mapping addresses 0 to 0x200000 to the first two megabytes of the physical address space. So, for example, virtual address 0xa3009 gets translated as physical address 0xa3009, which is of course not what you want, as it does not even point to system memory. You need to set up a mapping from the executable's linked address to the address where it actually resides in memory.

Actually, i mapped 256MB for the kernel. I just change the start address in linker at 1M to solve the problem. Thanks!

But i am not sure about the root cause.

There was no RAM at the addresses you were trying to use.

GRUB provides a memory map. You need to use that memory map to find available RAM.

Thanks!

[Gigasoft]

The problem isn't really solved, since the Multiboot2 header doesn't inform the loader of where the image needs to be loaded. This is going to cause surprises later on.

[rdos]

I think 0xA0000 to 0xFFFFF is reserved for BIOS, and so will not work as RAM. Of course, assuming linear addresses are equal to physical. In the absence of memory information, you should put the heap at 0x110000 or something.

[Octocontrabass]

The problem isn't really solved, since the Multiboot2 header doesn't inform the loader of where the image needs to be loaded.

The loader uses the ELF header.