* Question about ld_plugin_output_file_type and "-fpic" option
@ 2014-03-04 14:16 Alexander Ivchenko
2014-03-20 14:03 ` Alexander Ivchenko
2014-03-20 17:29 ` Cary Coutant
0 siblings, 2 replies; 4+ messages in thread
From: Alexander Ivchenko @ 2014-03-04 14:16 UTC (permalink / raw)
To: binutils, Cary Coutant
Hi,
Have a little question about ld_plugin_output_file_type in plugin-api.h.
"-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.
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?
thanks,
Alexander
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about ld_plugin_output_file_type and "-fpic" option
2014-03-04 14:16 Question about ld_plugin_output_file_type and "-fpic" option Alexander Ivchenko
@ 2014-03-20 14:03 ` Alexander Ivchenko
2014-03-20 17:29 ` Cary Coutant
1 sibling, 0 replies; 4+ messages in thread
From: Alexander Ivchenko @ 2014-03-20 14:03 UTC (permalink / raw)
To: binutils
Hi guys, could you please share some expertise on the question? I see
this LLVM's fail to produce position independent code executable with
"-fpic -flto", because it relies on ld_plugin_output_file_type and gcc
is not..
2014-03-04 18:16 GMT+04:00 Alexander Ivchenko <aivchenk@gmail.com>:
> Hi,
>
> Have a little question about ld_plugin_output_file_type in plugin-api.h.
>
> "-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.
>
> 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?
>
> thanks,
> Alexander
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about ld_plugin_output_file_type and "-fpic" option
2014-03-04 14:16 Question about ld_plugin_output_file_type and "-fpic" option Alexander Ivchenko
2014-03-20 14:03 ` Alexander Ivchenko
@ 2014-03-20 17:29 ` Cary Coutant
2014-03-20 19:22 ` Alexander Ivchenko
1 sibling, 1 reply; 4+ messages in thread
From: Cary Coutant @ 2014-03-20 17:29 UTC (permalink / raw)
To: Alexander Ivchenko; +Cc: binutils
> "-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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about ld_plugin_output_file_type and "-fpic" option
2014-03-20 17:29 ` Cary Coutant
@ 2014-03-20 19:22 ` Alexander Ivchenko
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Ivchenko @ 2014-03-20 19:22 UTC (permalink / raw)
To: Cary Coutant; +Cc: binutils
Thanks! It became much more clear now :)
--Alexander
2014-03-20 21:29 GMT+04:00 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-20 19:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-04 14:16 Question about ld_plugin_output_file_type and "-fpic" option Alexander Ivchenko
2014-03-20 14:03 ` Alexander Ivchenko
2014-03-20 17:29 ` Cary Coutant
2014-03-20 19:22 ` Alexander Ivchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).