Hi Rajiv, > Can anyone tell what is PIC (- Position independent code) in gcc. And what > is significance of flag_pic? Without PIC, code will be laid out at specific memory locations. For example, routine Foo() might be at 0x12340080 in memory, and the code will do jumps to that location rather than an indirect lookup of where Foo() is located. My understanding of PIC is that it is useful in situations where: + it is unknown where the code will be loaded The situations where that happens: + static shared libraries (SSO load of .so) + dynamic shared libraries (DSO dlopen of .so) + plug-ins (which are a special purpose shared library DSO) + archive libraries (link time .a) + operating systems which use physical memory addressing for all applications, rather then giving each PID it's own virtual memory space Certain architectures, such as the segmented memory architecture of the 8086/80286, reduce or eliminate the need for PIC, since the once the segment registers are properly set up the code is oblivious to the segment it is running in. (That is analogous in some respects to modern operating systems that give each PID it's own virtual memory space.) Loaders can do "fixups", which is different from PIC. In those situations, a library which might be expecting to load at 0x4000000 will be adjusted at load time to where it really resides. PIC can avoid a majority (but not not necessarily all) of the load time overhead. Note that pre-fixup, disassembly of the code will look funny. The fixup tables are calculated by the loader and the actual in-memory post-load (and post-fixup) code will be correct. (Pre-fixup the disassembly will look alarmingly wrong.) If you do disassembly, try to use a disassembly that is savvy to the fixup tables. The above is my understanding. I may have some of the particulars wrong, and if so, reflects my limited understanding. My use of "fixup" is probably incorrect terminology -- I wasn't sure of the industry term. HTH, --Eljay
