flag_pic significance

flag_pic significance

[Rajiv KI]

Hi all,

Can anyone tell what is PIC (- Position independent code) in gcc. And what
is significance of flag_pic?

Rajiv.
-- 
View this message in context: http://old.nabble.com/flag_pic-significance-tp27792093p27792093.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: flag_pic significance

[John (Eljay) Love-Jensen]

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

Re: flag_pic significance

[Ian Lance Taylor]

"John (Eljay) Love-Jensen" <eljay@adobe.com> writes:

> 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.

Usually people say "relocation."

More information at http://www.airs.com/blog/archives/41 .

Ian

RE: flag_pic significance

[Elden Crom]

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@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] 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