Memory access from C

[John Thomas]

The initial bootloader is binary, the stub connected to the front of the kernel is ELF, the kernel itself is ELF. It (the code) runs for sure, data is the problem. I can enter and exit functions, meaning that the stack is set up, I can now access memory directly using =, I can call assembly routines that are in the stub from the c program... etc.

Are you saying I have to find a way to perform the relocations myself in order to get elf working? Now I wish that BeOS could produce coff files...

I was planning on replacing the BIOS int 13 anyway. I suppose I'll have to learn more about elf...

Thanks for your exhaustive help, Tim... Back to the books.

[John Thomas]

I found out what the problem was. You were right, Tim, it was part of the elf format. You can execute code from the elf format, it seems, because the relocations are already set and in elf, the code section is mapped to physical memory, however the string section is not. In order to get to strings without relocating everything, you have to convert virtual memory to physical memory, and that (suprisingly) is done by subtracting the kernel offset (in this case 0x100000) from the strings virtual location to get the physical location. Beats me why I had to subtract the length of the string from that.

It is my job to write a routine that will perform the proper relocations. Oh well, now I know what it was.

[Pype.Clicker]

it is not weird that the code from a raw ELF file stored in memory will be able to call functions, but not to find its data: this is just because jumps and calls are usually defined as *relative* jumps, so regardless where the ELF has been put in memory, the offsets between functions remains constant and therefore you need no relocation to access code.
As there is no such thing as eip-relative memory addressing for data, all the MOVes to static datas (either vars or strings) must be relocated.

btw, did you made sure your %DS register was set when you call your C code ?

[Tim]

I can't say a lot now except give the usual answer: use GRUB as a boot loader. GRUB will handle ELF automatically for you.

[Chris Giese]

It's possible that GCC for BeOS produces position-independent code by default, without using any compiler switches.

Try compiling with [tt]gcc -fno-pic[/tt] (or maybe -fno-PIC ?) and see if that gets rid of _GLOBAL_OFFSET_TABLE_

[John Thomas]

Pype.Clicker:

That was my problem beforehand. I had failed to set the DS register. Once I did that, the problem with locating char *'s went away.

For now, I simply created an inline that converts virtual addresses to physical addresses and vice versa, that is, until I can write an elf loader.

Tim:

I have used grub before and I have no aversion whatsoever to it - it is an excellent bootloader. But I ask you this: Why would I be writing an OS if I wanted someone else to code it for me?

I felt as if I was cheating somehow. Maybe the bootloader isn't that important in the whole scheme of things, but I want to be able to say it's mine.

Chris:

Be Inc. did a lot of funky things to the gcc compiler when they ported it. I wouldn't be suprised if that was the case. I'll give it a shot.

[John Thomas]

Chris:

That was the problem. It seems as you said BeOS produces position independent code by default.

Thank you everyone. I finished up a primitive printf function yesterday, and some keyboard access using direct port I/O. I need to work on that elf loader, find a way to ditch BIOS to load sector 2, and probably start a HDD driver. That data will need to be relocated.

That's my priority, because I don't want to be calling s1 = virt_to_phys(s1) every time I need to access string data.