Hi all , first of all - sorry for my bad english..
one thing is not clear to me:when my mini os loads a file a then transfers control to there - how do i change program org?(of the loaded file) i mean , ofcourse it can't be changed - it's just a number whitch is added to every label position at compile-time - assuming that the file begins here, at an exact memory location.But this 'org' will be always different , because of memory allocation and other things...so my questing is how do i emulate (or what) this file-org? if i said something wrong , please notice me - i'll try to explain my problem with better words.Anyway - thanks for any help or answer.
program org
Re: program org
Hi,
You basically have two 3 options here:
#1 If you are running in real mode, or anything that would allow segmentation (IE: using different base address for CS/DS etc) then when you've loaded the code into memory you'd configure the segment registers base address to that address and ALL code would be compiled relative (org) to 0h.
Most modern OSes don't use this approach. It can be done in protected mode (32bit) as well by using up some of the 8192 available GDT entries.
Load the program, get its base.. create a new code and data 32bit descriptor with that base and put it in the GDT (or update pre-existing ones in the GDT).
#2 The preferred method as used by most OSes is that of paging. When you've loaded your code, created your task and process management structures etc, your OS/kernel would switch to that task and by so doing would re-configure paging so that the application THINKS it's running at a specified address (say 0) even though in physical memory it lives somewhere else.
#3 A more complex and fiddly approach and not so common would be to load the code to your physical memory address, the code would all be compiled relative to some address (possibly 0h again) and then you kernel would scan the code and perform the relocations / modifications necessary to re-base the code.
You basically have two 3 options here:
#1 If you are running in real mode, or anything that would allow segmentation (IE: using different base address for CS/DS etc) then when you've loaded the code into memory you'd configure the segment registers base address to that address and ALL code would be compiled relative (org) to 0h.
Most modern OSes don't use this approach. It can be done in protected mode (32bit) as well by using up some of the 8192 available GDT entries.
Load the program, get its base.. create a new code and data 32bit descriptor with that base and put it in the GDT (or update pre-existing ones in the GDT).
#2 The preferred method as used by most OSes is that of paging. When you've loaded your code, created your task and process management structures etc, your OS/kernel would switch to that task and by so doing would re-configure paging so that the application THINKS it's running at a specified address (say 0) even though in physical memory it lives somewhere else.
#3 A more complex and fiddly approach and not so common would be to load the code to your physical memory address, the code would all be compiled relative to some address (possibly 0h again) and then you kernel would scan the code and perform the relocations / modifications necessary to re-base the code.
Re: program org
Assuming I understand your post right, you can store the org (preferred base address) in a variable within the binary itself so the system knows how to load it. This is normally done in a programs file header structure. Of course, assuming the program is in a HLL, this is a little harder to do. This is why it is recommended to use a more widely used file format such as ELF or PE ...because more compiliers nativity support it.lama wrote:so my questing is how do i emulate (or what) this file-org?
PE and (I believe) ELF also support relocation allowing you to rebase where the program needs to be loaded at.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: program org
that was quick 
thanks - but reconfigure how? i'll find free pages, set present and r/w bit here (000000000011b) and at the top of the first page write the physical address..?i have thougt about the third option too - but that would be really slow and uncomfortable, right?(i mean basicly recalculate all that stuff)
thanks again for the answer
thanks - but reconfigure how? i'll find free pages, set present and r/w bit here (000000000011b) and at the top of the first page write the physical address..?i have thougt about the third option too - but that would be really slow and uncomfortable, right?(i mean basicly recalculate all that stuff) thanks again for the answer
-
Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: program org
It's not really slow and it's used all the time for shared libraries (such as DLLs). In 64-bit mode (on x86_64s at least) you even have some hardware support for relocations.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: program org
#4 Use relocation table to be able to relocate the code to the actual load address. Every absolute memory reference has to be updated in the image if loaded at an address differing from the default address.johnsa wrote:Hi,
You basically have two 3 options here:
Re: program org
No, that's just the #3 he mentioned.skyking wrote:#4 Use relocation table to be able to relocate the code to the actual load address. Every absolute memory reference has to be updated in the image if loaded at an address differing from the default address.
#4: Use position independent code (PIC)
Can also be used with paging, allowing address space randomization. And is great for DLLs/.so-s as well, of course.
JAL