Entry point of ELF File at 0x00000000!

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: Entry point of ELF File at 0x00000000!

Post by xenos »

requimrar wrote:I think I just did… I don't know what defines '64-bit code', but I can execute code in a 64-bit elf by jumping directly to it. Probably a bad idea though.
When you're in long mode with a 64-bit code segment, you can execute code compiled with a 64 bit compiler or assembled with some 64 bit assembler, maybe using the .code64 directive if you had some .code32 stub before.
Yes, I'm using QEMU. Is that some kind of anomaly?
Actually I never encountered such a delay in QEMU, so I don't think it's a general thing about QEMU. But it's hard to tell where this may come from.
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
User avatar
zhiayang
Member
Member
Posts: 368
Joined: Tue Dec 27, 2011 7:57 am
Libera.chat IRC: zhiayang

Re: Entry point of ELF File at 0x00000000!

Post by zhiayang »

XenOS wrote:
requimrar wrote:I think I just did… I don't know what defines '64-bit code', but I can execute code in a 64-bit elf by jumping directly to it. Probably a bad idea though.
When you're in long mode with a 64-bit code segment, you can execute code compiled with a 64 bit compiler or assembled with some 64 bit assembler, maybe using the .code64 directive if you had some .code32 stub before.
Yes, I'm using QEMU. Is that some kind of anomaly?
Actually I never encountered such a delay in QEMU, so I don't think it's a general thing about QEMU. But it's hard to tell where this may come from.

I see, thanks for clarifying. Anyway, now that I've gotten a call-able function pointer to my kernel, I'm just going to work on my PMM for now.

Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?

I'm thinking A… but of course it doesn't seem right.
One last question: GRUB says my kernel is about 2MB+. That doesn't seem right, given that

a. My ASM file is just 1 BITS directive, one extern and one global directive, a section marker, a label, a cli, a hlt and a call instruction, and

b. My C file is a void main(), setting an int pointer to 0xB8000, writing A to 0xB8000 and 0x0F to 0xB8001…

Why?
User avatar
Nessphoro
Member
Member
Posts: 308
Joined: Sat Apr 30, 2011 12:50 am

Re: Entry point of ELF File at 0x00000000!

Post by Nessphoro »

Force the page size to 4 kb
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Entry point of ELF File at 0x00000000!

Post by bluemoon »

requimrar wrote:Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?
For me it is simple, refuse to boot; and nobody complaint so far (well, I have zero user base, and chances for any user with such machine is so remote that it's not justified to support it).
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Entry point of ELF File at 0x00000000!

Post by Combuster »

requimrar wrote:Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?
Link it at 0x00100000 instead, so you can have more machines on which it works. Although being unable to fit your kernel within the first 4MB of RAM indicates other problems and "no" is also an answer.
One last question: GRUB says my kernel is about 2MB+. That doesn't seem right
Well, with your post count, I would expect you'd be able to give a better description than that? If the end result is not what you expect, break the process up into the individual steps. Know your tools. Check your actual filesizes on disk and use objdump to find out what's actually stored as metadata within the files.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
zhiayang
Member
Member
Posts: 368
Joined: Tue Dec 27, 2011 7:57 am
Libera.chat IRC: zhiayang

Re: Entry point of ELF File at 0x00000000!

Post by zhiayang »

Combuster wrote:
requimrar wrote:Just a question: Say the kernel wants to be loaded at 0x002F0000. However, that space is either
a. Reserved (Type 2) or
b. Non-existant.

Should I
a. Screw what it wants, and just shove it in whatever nook and cranny I have for free memory, or
b. Figure out relocations and stuff?
Link it at 0x00100000 instead, so you can have more machines on which it works. Although being unable to fit your kernel within the first 4MB of RAM indicates other problems and "no" is also an answer.
One last question: GRUB says my kernel is about 2MB+. That doesn't seem right
Well, with your post count, I would expect you'd be able to give a better description than that? If the end result is not what you expect, break the process up into the individual steps. Know your tools. Check your actual filesizes on disk and use objdump to find out what's actually stored as metadata within the files.
I *am* linking at 0x00100000, So no problems there. It's a theoretical question, but I get your point.

My post count… I never looked at that :P I'm taking a break from that currently, but I'll get to work soon enough.
Post Reply