From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3647 invoked by alias); 20 Mar 2014 19:22:46 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 3632 invoked by uid 89); 20 Mar 2014 19:22:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pb0-f51.google.com Received: from mail-pb0-f51.google.com (HELO mail-pb0-f51.google.com) (209.85.160.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 20 Mar 2014 19:22:44 +0000 Received: by mail-pb0-f51.google.com with SMTP id uo5so1386457pbc.38 for ; Thu, 20 Mar 2014 12:22:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.41.106 with SMTP id e10mr49286765pal.109.1395343362304; Thu, 20 Mar 2014 12:22:42 -0700 (PDT) Received: by 10.68.54.4 with HTTP; Thu, 20 Mar 2014 12:22:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Mar 2014 19:22:00 -0000 Message-ID: Subject: Re: Question about ld_plugin_output_file_type and "-fpic" option From: Alexander Ivchenko To: Cary Coutant Cc: binutils Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00237.txt.bz2 Thanks! It became much more clear now :) --Alexander 2014-03-20 21:29 GMT+04:00 Cary Coutant : >> "-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