>The vast majority of it probably is, some of it isn't and it'll depend on >the architecture...
So isn't there a thick line that this code is PIC and this is not? What I understand is that on any arch code, which runs before enabling paging unit must be PIC. Is that correct? And one more question - can we load linux image any where in the memory and run? Thanks - A. On 1/24/08, Rene Herman <[EMAIL PROTECTED]> wrote: > > 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. > >
