[NSWI004] Commiting results of assignment

[Petr Tůma]

Hi,

On 21/10/2019 23:37, Pavel Vigilev wrote:
>> On Mon, Oct 21, 2019 at 9:15 PM Petr Tůma <petr.tuma at d3s.mff.cuni.cz <mailto:petr.tuma at d3s.mff.cuni.cz>> wrote:
>>     when do you say "allocate all available space", what exactly do you mean ? (= what code do you use to allocate memory ?)
>
> Up to the type-cast something like this:
> size_t n = 1;
> while(true){
>      uint32_t buf[n];
>      if(buf - _kernel_end < 2*sizeof(uint32_t) && buf + n - 1 - _kernel_end < 2*sizeof(uint32_t))
>           break;
> }
> return n;
> 
> But there is a problem that the _kernel_end is always 0x0. Anyway, if I will print the first and the last addresses of the buf it will crash when the buf will be <1kB.

Two issues here.

One, the way you allocate buf is not something that helps here. The allocation is on stack, and stack is set in the head.S file to address 0x80000400, growing downwards, so you would only be able to allocate around 1 kilobyte before things go down the drain (stack going below 0x80000000 is a problem since there is no memory there).

It helps to realize what the memory map of your system looks like:

- addresses 0 to 7ffffffffh are user mode addresses and do not work yet, so ignore those
- your kernel image starts at address 80000000h and continues to _kernel_end
- after _kernel_end there is the unused memory whose size you should detect
- and some time later after _kernel_end there is again no memory

Remember, your system currently has no way to allocate memory in the range you are supposed to examine. Stack allocations go to the addresses mentioned above, there is just a small space reserved for your stack and it grows in the wrong direction anyway. And heap allocations are not available because there is no heap yet. So you cannot use allocation attempts, you have to try something else.

And issue two. The _kernel_end symbol is a variable at the end of the kernel, so you do not want to take its value, you want to take its address. That will definitely not be 0.

I'm CCing the mailing list because this is an interesting attempt you made with the stack allocation and other people might also benefit from thinking about what is happening there.

Petr