Re: Question about ld_plugin_output_file_type and "-fpic" option

[Cary Coutant <ccoutant@google.com>]

> "-fpic" option is turned on by default for Android compiler (both gcc
> and llvm), so if we run the compiler on a .c file and get an
> executable - it will be compiled and linked as position independent
> code (e.g. no COPY relocs).
>
> However, if we add an lto mechanism into account, the thing will be
> different. As far as I understand, for gcc case "-fpic" option will be
> given through temporary file, but llvm will rely on
> ld_plugin_output_file_type of the linker, which in the case described
> above would be just LDPO_EXEC which is not position independent. And
> so for "-fpic" and lto we will get copy relocations and stuff.

GCC records most of the options (excluding some like front-end and
driver-specific options) in the IR file so that it can use the same
options when it does the link-time translation (LTRANS). It sounds
like LLVM isn't doing that (or at least isn't recording the -fpic
option). If true, that sounds to me like a bug in LLVM.

> Since we allow to compile and link an executable with "-fpic" (I know
> that it is recommended to make an executable "-fpie" but I'm
> describing how the default compiling is done) what are the assumptions
> on a resulting executable? Should there be another entry in
> ld_plugin_output_file_type for that? "-fpic" is not given to a linker
> in any way, can we say that the resulting executable will be a
> position independent?

No, the compiler shouldn't depend on the output file type to determine
what compile-time options are needed -- there are too many options and
this would result in a combinatorial explosion.

The LDPO_PIE option is there because -pie is a linker option, and the
compiler has no other way of knowing that it's generating code for a
PIE (the design originally assumed that the -fpie compiler option
would be passed to all translation units, but was added later to allow
the optimizer more flexibility).

-cary