On 24-01-08 14:02, sahlot arvind wrote:
That makes sense. Thanks a lot. So position independent code is one wherein all the branch instructions are PC relative. Right?
More the other way around -- if all branches are PC relative you'll get position independent code (codewise that is; it's perfectly possible to still depend on the position explicitly if your code tries, ofcourse).
More generally though, position independent code might also just be such by virtue of having absolute branches fixed up during loading the executable. DOS did this for example, as does gcc code compiled with -fpic via an extra table indirection.
And is the entire Linux Kernel Position Independent Code???
The vast majority of it probably is, some of it isn't and it'll depend on the architecture...
That isn't particularly definitive but once you run at the address you told the linker you would be running at (that is, after enabling paging) there's not actually anything functionally wrong with hardcoded addresses so a compiler is in principle free to generate such code -- wouldn't even have a choice on architectures that do not implement relative branching. Not that I think that there are any, but in essence you can consider this an implementation detail.
On ia32, near (*) jumps and calls can be both relative and absolute and gcc generates relatives rather exclusively it would seem. You'll always need a few absolute branches for things such as reloading segment registers after mucking about with low level things such as enabling protection and paging but most of the code turns out to be position independent yes.
(*) with "near" being defined as inside a single segment -- Linux doesn't use segmentation so everything is near, with some minor exceptions such as APM.
Rene. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
