#12430: gcc 4 won't build a non-position-independent executable
--------------------------+----------------------------
Reporter: simonsouth | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: System | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
--------------------------+----------------------------
Comment (by simonsouth):
Here is a set of patches that correct this issue.
The first patch modifies gcc's `CC1_SPEC` and `LINK_SPEC` strings to
* Include `-fno-PIC` and `-fno-PIE` as command-line options that disable
the generation of position-independent code (and remove the non-existent
`-no-fpic` option).
* Use `-fPIC` by default in place of `-fpic` to compile without
restriction on the size of the global offset table (this matters
[https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Code-Gen-Options.html#index-
fPIC-2392 only on m68k and ppc], and is [http://cgit.haiku-
os.org/buildtools/tree/gcc/gcc/config/rs6000/haiku.h#n59 already the
default on ppc]; users can still request this limit with `-fpic`).
* Pass `-shared` to the linker only if it was passed to gcc.
* Output position-independent executables by default, and request them
specifically with the `-pie` linker option, allowing undefined symbols in
shared libraries and exporting all symbols to match the behaviour of
shared-object "executables" today.
The remaining patches are optional but complete the implementation. In
order, they
* Wrap the `CC1_SPEC` and `LINK_SPEC` strings neatly at 80 columns.
* Gently refactor the `LINK_SPEC` string for several platforms,
consolidating sequences and using a more compact notation without any
change in functionality.
* Set the ELF interpreter on generated executables.
Now that gcc is outputting "real" PIEs and not shared objects
masquerading as them, the linker includes an `INTERP` segment in the ELF
header requesting a specific interpreter to launch the program. This final
patch (against ld) changes the contents of this section from the UNIX-y
default to something more accurate and distinctly //Haiku//.
With these patches applied
* **The default behaviour of gcc is not changed.** Position-independent
executables are still generated by default, and these still participate in
dynamic linking exactly as they do today.
* Pre-existing executables function just as they do currently and can
still be used as link targets.
* Users can ask gcc to build a non-position-independent executable with
the `-fno-pic` or `-fno-pie` options, and the request will be honoured
(and with the patch for #12427 applied, the generated executable will
run).
* gcc now //says what it means//: When it //means// to build a position-
independent executable, it //says so// explicitly by passing the `-pie`
option to the linker. No longer does it request a shared object that just
happens to function like a PIE.
* An INTERP segment is included in every executable that identifies it as
//built for Haiku// with a pointer to `/system/runtime_loader`. This is
[http://cgit.haiku-
os.org/haiku/tree/src/system/runtime_loader/elf_load_image.cpp#n190
ignored by runtime_loader today], but (aside from the vanity aspect) could
be useful down the road to distinguish between 32- and 64-bit executables
on x86_64, or to support seamless execution of BeOS and Haiku executables
together.
--
Ticket URL: <https://dev.haiku-os.org/ticket/12430#comment:2>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
