code relocation
code relocation
Hi can somebody show me some read&digest type of (I mean not real official references ;D) tutorials on internet about code relocation and its impacts on os implementation? Thanx a bunch...
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:code relocation
here comes a short description of how relocation is handled for Clicker kernel modules
Basically the relocations are just a list of positions in the file where there are references to absolute addresses. If one needs to load the file at another address than the "build" address, absolute references must be changed either at load-time or at run-time (lazy relocation).
Afaik, Windows Serie uses a relocation-based dynamic loading while Linux uses position-independent code. PIC requires the permanent locking of a global register and pretty complicated structures like the procedure linkage table or the Global Offset table, which i can't describe because i don't know them very well.
Despites it makes loading and code sharing efficient (i.e. if you have 10 instance of a shared .so in linux, they all use the very same copy of pages and those pages come directly from the disk), PIC has the major drawback of locking the "module base register" -- which may be very limitative in IA-32 because there are already a lack of generic registers ...
System based on relocations may have more efficient code (once loaded) because you have one more register to carry out operations. However, special care must be taken to reduce the amount of relocation effectively performed: everytime the system will have to relocate a page, this page is no longer the exact copy of what is on the disk (though we still can avoid swapping that page out by applying relocations just after the page has been mapped from the file ;-p ).
Moreover, if 2 process map the same object at different locations, the relocations will be different, and thus the 2 instance of the object cannot share their physical pages. This means the default address of a shared object is very important and that a policy must be installed to help keeping the same object at the same location (even in different process)
Basically the relocations are just a list of positions in the file where there are references to absolute addresses. If one needs to load the file at another address than the "build" address, absolute references must be changed either at load-time or at run-time (lazy relocation).
Afaik, Windows Serie uses a relocation-based dynamic loading while Linux uses position-independent code. PIC requires the permanent locking of a global register and pretty complicated structures like the procedure linkage table or the Global Offset table, which i can't describe because i don't know them very well.
Despites it makes loading and code sharing efficient (i.e. if you have 10 instance of a shared .so in linux, they all use the very same copy of pages and those pages come directly from the disk), PIC has the major drawback of locking the "module base register" -- which may be very limitative in IA-32 because there are already a lack of generic registers ...
System based on relocations may have more efficient code (once loaded) because you have one more register to carry out operations. However, special care must be taken to reduce the amount of relocation effectively performed: everytime the system will have to relocate a page, this page is no longer the exact copy of what is on the disk (though we still can avoid swapping that page out by applying relocations just after the page has been mapped from the file ;-p ).
Moreover, if 2 process map the same object at different locations, the relocations will be different, and thus the 2 instance of the object cannot share their physical pages. This means the default address of a shared object is very important and that a policy must be installed to help keeping the same object at the same location (even in different process)
Re:code relocation
Windows' relocation scheme assumes that relocation will be needed only rarely. Linux's assumes that there are enough CPU registers that one can be dedicated to PIC.
Windows' scheme is zero-cost only when nothing needs to be relocated, so it's important to choose your DLL base addresses correctly. AFAIK the cost of Linux's scheme is constant.
Windows' scheme is zero-cost only when nothing needs to be relocated, so it's important to choose your DLL base addresses correctly. AFAIK the cost of Linux's scheme is constant.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:code relocation
Note that ELF is initially designed for SPARC-like machines that have plenty of global registers in addition to local registers (that are only valid in the current function) ... So PIC makes more sense there :pTim Robinson wrote: Windows' relocation scheme assumes that relocation will be needed only rarely. Linux's assumes that there are enough CPU registers that one can be dedicated to PIC.
Windows' scheme is zero-cost only when nothing needs to be relocated, so it's important to choose your DLL base addresses correctly. AFAIK the cost of Linux's scheme is constant.
Making it work on a machine that has few registers and no relative addressing is pretty much challenging ...