OSDev.org

hello everyone there,

i 've been trying to load the kernel with different virtual addreses .

but not at all succeeding.i think i've tried a lot of research and also

continuing with it. i'm finding it very difficult.

seeking for help . . . . . .

OK, what have you tried? Why do you think it is failing? What do you intend to try to make it work?

Tim Robinson wrote: I don't think you can when using ELF. I think you've got to keep your virtual address within the range of physical memory. Can any ELF experts confirm or deny this?

You can, but only when using paging (which the multiboot standard doesn't support, as you know). There is no execution format that can link to a nonphysical address and resolve that with solely segmentation (unless you want to resort to your old tricks, which have proven that they are very complex and unreliable to me).

As for the physical/virtual thingy, ELF does let you insert both a virtual and a physical value in the header, for the applications where it does matter where it's loaded. Just don't think grub is gonna like it.

grub does the correct stuff. It cares about the physical adress given to the linker.

one has to do some adress corrections to get the stuff running prior to activating paging because of the virtual adresses in the program (kernel)

BI lazy wrote: grub does the correct stuff. It cares about the physical adress given to the linker.

one has to do some adress corrections to get the stuff running prior to activating paging because of the virtual adresses in the program (kernel)

Linkers don't use physical addresses, ever. They only know the virtual addresses.

As for the point you are making, you could also make a kernel-starter bit of code that sets up paging, resolving the entire boot to final conversion you use.

how can i set up paging ?
plz explain. . . . . . . . .

neuRopac: Go to http://www.osdever.net/tutorials.php?cat=6&sort=1. Read all the tutorials there. If, after you have read and attempted to understand them, you still have questions, then please come back here and ask. But do make an effort to learn for yourself before asking for help.

@candy: hmmm ... and what's that phys= ... in the linker script good for then? *frowning slightly*

Well, your point about a kernel-starter bit of code: I didn't say that I ever omitted this one. You *need* a kernel starter bit of asm to get the machine running properly and to set up some crucial prerequisites like some pagetables and a pagedirectory, but whom I am talking to? You seem to know your stuff.

BI lazy wrote: @candy: hmmm ... and what's that phys= ... in the linker script good for then? *frowning slightly*

Thx for the compliment

As for actually using them, they don't. All a physical address is at link time is a future reference, something that is of interest, belongs with the program, but is completely not useful now. The linker puts together the program with all respect for the virtual addresses, but no respect for the physical addresses, since they are to be separated from him using paging or the like. There are only two possible ways it could insert it into the end file:

1. It simply forwards it to the header. As with ELF headers, they support this, so it would be useful to have a passthrough to the header, but not for use.
2. As addition to the previous, with fixed physical addresses it might be able to detect overlapping sections, but I doubt any linker does this (since it only has extremely limited practical application).

Tim Robinson wrote:

Pype.Clicker wrote:So how do we define the virtual address that GRUB should use ?

I don't think you can when using ELF. I think you've got to keep your virtual address within the range of physical memory. Can any ELF experts confirm or deny this?

Out of the ELF documentation:

p_paddr :
On systems for which physical addressing is relevant, this member is reserved for the segment's physical address. Because System V ignores physical addressing for application programs, this member has unspecified contents for executable files and sharedobjects.

So it looks like most loader ignore the 'physical address' stuff... I'm not sure on how GRUB's loader actually handles it, though