I believe your descriton to be correct. The name of the 'fixup table's are called 'relocation tables', and are usually carried along with *.o files but removed by the linker (after using them) when the final executable is created for most systems. In other systems (such as ucLinux) that also allow the invocation of several programs at once that are unknown at compile time (ie they have a command shell like bash) that do not have an MMU, the relocation tables are left in the executable so that the kernal can put them anywhere in memory and then fixup the jump tables. UcLinux uses a special version of the linker to allow for this (elft2flt) which hopefully will be incorperated as a flag to gcc's ld and collect2....someday. See http://www.beyondlogic.org/uClinux/bflt.htm for a better description how uclinux uses the relocation tables. -----Original Message----- From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On Behalf Of John (Eljay) Love-Jensen Sent: Friday, March 05, 2010 5:32 AM To: Rajiv KI; GCC-help Subject: Re: flag_pic significance 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
