Add support for producing position-independent executables
ClosedPublic

Authored by bgamari on May 15 2017, 4:56 PM.

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
bgamari created this revision.May 15 2017, 4:56 PM
bgamari updated this revision to Diff 12602.May 15 2017, 5:07 PM

Use -pie instead of -fPIE

rwbarton requested changes to this revision.May 15 2017, 5:09 PM

I'm confused about whether the new flag is to be named -fPIE, -PIE or -pie.

Test?

This revision now requires changes to proceed.May 15 2017, 5:09 PM
bgamari updated this revision to Diff 12604.May 15 2017, 5:17 PM
bgamari edited edge metadata.

Fix capitalization

I'm confused about whether the new flag is to be named -fPIE, -PIE or -pie.

Indeed I went through a few options. Ultimately I settled on -pie, which is consistent with gcc. Does this seem reasonable to you?

I've fixed the inconsistency in DynFlags.hs.

Test?

In the process of writing one.

bgamari updated this revision to Diff 12605.May 15 2017, 5:27 PM

Add test

jrtc27 added a subscriber: jrtc27.May 15 2017, 5:27 PM

The command-line flags are somewhat confusing. For GCC, you compile with -fpie/-fPIE and link with -pie, and I think there's no guarantee that code compiled with -fPIC can be statically linked into a position-independent executable, although in practice I believe it's fine. Personally, I think GHC should accept -fPIE and treat it like -fPIC (with the option to behave differently in future should it so desire, so long as it continues to work for PIE) for compilation, and use this -pie option to govern linking.

compiler/main/DynFlags.hs
517

This is a weird name; in my opinion this should either be Opt_PIE or Opt_PIExecutable (preferring the former as that's what everyone calls it).

3331

The option -pie should be lower-case.

3332

Ditto for -no-pie.

Here's a test.

bgamari updated this revision to Diff 12606.May 15 2017, 5:33 PM

Make it build

bgamari marked 2 inline comments as done.May 15 2017, 5:36 PM
bgamari added inline comments.
compiler/main/DynFlags.hs
517

This name was inspired by the --pic-executable flag accepted by ld. I wanted to avoid Opt_PIE due to confusion with -fPIC and Opt_PIC.

3331

Fixed.

bgamari marked an inline comment as done.May 15 2017, 5:37 PM

The command-line flags are somewhat confusing. For GCC, you compile with -fpie/-fPIE and link with -pie, and I think there's no guarantee that code compiled with -fPIC can be statically linked into a position-independent executable, although in practice I believe it's fine. Personally, I think GHC should accept -fPIE and treat it like -fPIC (with the option to behave differently in future should it so desire, so long as it continues to work for PIE) for compilation, and use this -pie option to govern linking.

This sounds reasonable to me. Do you think that -pie should imply -fPIE?

The command-line flags are somewhat confusing. For GCC, you compile with -fpie/-fPIE and link with -pie, and I think there's no guarantee that code compiled with -fPIC can be statically linked into a position-independent executable, although in practice I believe it's fine. Personally, I think GHC should accept -fPIE and treat it like -fPIC (with the option to behave differently in future should it so desire, so long as it continues to work for PIE) for compilation, and use this -pie option to govern linking.

Actually, what in particular do you mean? Do you think we should have both an Opt_PIE and Opt_PIC with corresponding flags? Alternatively, do you think that -fPIC and -fPIE should both affect Opt_PIC? The problem with the latter is that things like -fPIC -fno-PIE would have rather surprising behavior (although I frankly can't imagine why anyone would expect this to work anyways).

The command-line flags are somewhat confusing. For GCC, you compile with -fpie/-fPIE and link with -pie, and I think there's no guarantee that code compiled with -fPIC can be statically linked into a position-independent executable, although in practice I believe it's fine. Personally, I think GHC should accept -fPIE and treat it like -fPIC (with the option to behave differently in future should it so desire, so long as it continues to work for PIE) for compilation, and use this -pie option to govern linking.

This sounds reasonable to me. Do you think that -pie should imply -fPIE?

While that might be the logical thing to do if starting from scratch, both of these are independent in GCC. If you give -fPIE but not -pie, it generates code suitable for PIE, but doesn't tell the linker to generate a position-independent executable, so you get a normal position-dependent executable. If you give -pie but not -fPIE, you either get linker errors because code generation assumed it was position-dependent and leads to incompatible relocations, or the linker silently allows it but crashes at runtime (depends on the architecture and linker used).

The command-line flags are somewhat confusing. For GCC, you compile with -fpie/-fPIE and link with -pie, and I think there's no guarantee that code compiled with -fPIC can be statically linked into a position-independent executable, although in practice I believe it's fine. Personally, I think GHC should accept -fPIE and treat it like -fPIC (with the option to behave differently in future should it so desire, so long as it continues to work for PIE) for compilation, and use this -pie option to govern linking.

Actually, what in particular do you mean? Do you think we should have both an Opt_PIE and Opt_PIC with corresponding flags? Alternatively, do you think that -fPIC and -fPIE should both affect Opt_PIC? The problem with the latter is that things like -fPIC -fno-PIE would have rather surprising behavior (although I frankly can't imagine why anyone would expect this to work anyways).

Whatever GCC does, which actually seems to allow that (it behaves like -fPIC as you might expect to be the logical outcome). I guess that means you need an Opt_PIE for -fPIE, and something else for -pie (Opt_Pie or Opt_pie would be far too confusing....). That would also be a pain for all the places which check for Opt_PIC though...

bgamari updated this revision to Diff 12607.May 15 2017, 6:36 PM

It works!

bgamari updated this revision to Diff 12608.May 15 2017, 6:55 PM

Fix patch

bgamari updated this revision to Diff 12609.May 15 2017, 7:01 PM

Add test output

trofi added a subscriber: trofi.May 16 2017, 3:03 AM
trofi added inline comments.
compiler/main/SysTools.hs
1542

The code around looks like it handles only libraries, not final executables.

bgamari added inline comments.May 16 2017, 8:25 AM
compiler/main/SysTools.hs
1542

Indeed, I have a patch which removes this in fact. I jus didn't want to merge it with this patch.

-pie seems reasonable to me. But couldn't -shared be used for this? There's an arguable consistency to it: -shared makes a dynamically-loadable library, it would be nice if it did the same thing for an executable.

-pie seems reasonable to me. But couldn't -shared be used for this? There's an arguable consistency to it: -shared makes a dynamically-loadable library, it would be nice if it did the same thing for an executable.

I suppose so. It's a bit inconsistent with what gcc does, but as I've stated in the past I'm not convinced that gcc is a great model to emulate.

bgamari retitled this revision from Add support for producing position-indepedent executables to Add support for producing position-independent executables.Jun 24 2017, 2:42 PM

-pie seems reasonable to me. But couldn't -shared be used for this? There's an arguable consistency to it: -shared makes a dynamically-loadable library, it would be nice if it did the same thing for an executable.

I suppose so. It's a bit inconsistent with what gcc does, but as I've stated in the past I'm not convinced that gcc is a great model to emulate.

Actually, back up a bit; I'm not sure I understand the suggestion. AFAIK we currently have no flag to select between producing an executable (that is, something with an entrypoint provided by libHSrts) and a library. As I understand it, -shared currently changes GHC's behavior to produce a shared library instead of an executable. Are suggesting that we change this (e.g. always link against libHSrts when run with -shared)? Under what conditions should this happen?

The suggestion was probably misguided, just ignore it.

bgamari updated this revision to Diff 13057.Jul 7 2017, 6:49 PM
  • Don't pass PIE flags when linking dynamic libraries
  • Introduce -fPIE
  • Fix it
  • Fix test
This revision was automatically updated to reflect the committed changes.