Here's my latest.
Trying to get position independent flat binary (it is the ELF loader)
Linked to address 0x00000000
which will first run at 0x01000000
Sets itself to an API function (somewhere between 0xE4200000 and 0xFF000000)
Then load the ELF modules attached to the tail of the binary (at the 0x01000000 position)
---- The modules actually start at 0x01001000 due to the binary being 4KB
And again this is flat binary and written in C.
Turns out only line I needed to add was for the name pointer:
Code:
char *ModVirt = (char*) ((uint32_t)ModName + 0x01000000); // Fix the pointer
*Note this line is only ever run from the base of 0x01000000 - that's how I got away with it
And everything else relies on pointers provided by other applications (which hopefully are valid and mapped in said apps space)
So, two days of trying to compile PIC to find it is easier than I thought.
And to think an hour before I tried this I was about to call it quits on C - but I dislike data management in ASM
Looks like we are getting somewhere now. For the kernel only being two weeks old (and my first Exo) not too bad.
Hopefully tonight's update will have at least some of my old modules ported over.
So here are my test result:
Code:
BOS v. 0.0.4 SRC/i386/memory/virtual.c Compiled at 13:25:36 on Sep 14 2015 Line 334 Function "_VMM_PageFaultManager"
User Task Attempted to Write a Non-Present page!
Virtual Address: 0xCFFFFFFB
User Task Faulted In User Stack
Expanding Stack
EAX = 0x26000
aaaaa.....a
Yes my first elf just puts 'a' and yields. And the EAX refers to the new Page Directory (Physical Address) created for the ELF