[Bug c++/35500] New: Documentation for -fPIC/-fpic/-fpie is not clear

[Bug c++/35500] New: Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

Documentation for -fpic and family is not clear. Here are the points I would
like clarified:
   - Does pic required for SOs (No)? 
   - What are the upsides/downsides of using pic (faster SO loading vs run-time
hit, others?)?
   - Why would anybody want to create a PIE?


-- 
           Summary: Documentation for -fPIC/-fpic/-fpie is not clear
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ddenisen at altera dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-07 19:39 -------
DSO requires PIC code.

PIC means is it produces position independent code.
PIE means it produces code for position independent executable, not DSOs
though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

------- Comment #2 from ddenisen at altera dot com  2008-03-07 19:45 -------
But DSOs still work if I don't use PIC. Why is that?

Why would anybody want to create position-independent executable? What are the
advantages and disadvantages?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-07 19:47 -------
(In reply to comment #2)
> But DSOs still work if I don't use PIC. Why is that?

Depends on the target :).  If this is x86, then you can guess why.  In fact
x86_64 errors out when linking if you did not use -fPIC (or -fpic).

> Why would anybody want to create position-independent executable? What are the
> advantages and disadvantages?

Security, random addresses for the text section.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

------- Comment #4 from ddenisen at altera dot com  2008-03-07 20:11 -------
I am still learning about linking and loading and I can't guess why non-PIC
DSOs would work on x86 but not on x86_64. Could you please explain briefly.

This is all very useful information that I couldn't find anywhere else (I guess
I could always look at gcc code :) ). Can the following be added to
documentation?

(for -fpic): PIC is required for DSOs on x86_64 platform but not for x86.
(for -fpie): One example of using -PIE is security: text section of
position-independent executable can be located at different addresses for each
invocation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[brian at dessent dot net]

------- Comment #5 from brian at dessent dot net  2008-03-07 23:48 -------
Subject: Re:  Documentation for -fPIC/-fpic/-fpie is not clear

> I am still learning about linking and loading and I can't guess why non-PIC
> DSOs would work on x86 but not on x86_64. Could you please explain briefly.
> 
> This is all very useful information that I couldn't find anywhere else (I guess
> I could always look at gcc code :) ). Can the following be added to
> documentation?

PIC is always required for DSOs, at least on unix/ELF-like targets. 
It's just that one platform in particular lets you get away with linking
non-PIC code into a .so, namely x86.  All (?) other architectures will
give a link time error if you try to do this.  So it's horribly
non-portable and it really just works by accident.  And it loses most of
the advantages of shared libraries to put non-PIC code in a .so: text
relocs.  This prevents sharing of code pages between processes, so
really the .so is no longer shared from a memory footprint standpoint
since each process will have its own dedicated copy as the .text section
needs to be modified (relocated).  This also has a startup cost.

This kind of thing can't really be easily documented in the gcc manual
because it's platform specific.  gcc is not just a compiler for x86 or
Linux, it supports dozens and dozens of platforms/targets and they each
have different semantics of how shared libraries work -- if they even
have shared libraries.  For example there might be x86 platforms that
don't even have shared libraries, like bare metal or a.out targets, so
you can't even make any definitive statements about x86.  So while "x86
linux" may be common it is most certainly not the only thing gcc is used
with.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

[ddenisen at altera dot com]

------- Comment #6 from ddenisen at altera dot com  2008-03-10 14:14 -------
Thank you everybody for the feedback. I'm setting the bug to fixed.


-- 

ddenisen at altera dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500