[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear
--- 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
[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear
--- 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
--- 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
--- 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
--- 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
--- 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
