From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6973 invoked by alias); 7 Nov 2011 15:57:12 -0000 Received: (qmail 6962 invoked by uid 22791); 7 Nov 2011 15:57:11 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 15:56:50 +0000 Received: from eggs.gnu.org ([140.186.70.92]:33731) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1RNRZ4-0000W2-08 for gcc-help@gnu.org; Mon, 07 Nov 2011 10:56:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNRZ1-0003Bw-Ug for gcc-help@gnu.org; Mon, 07 Nov 2011 10:56:49 -0500 Received: from mail-vx0-f169.google.com ([209.85.220.169]:42291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNRZ1-0003Bk-Pu for gcc-help@gnu.org; Mon, 07 Nov 2011 10:56:47 -0500 Received: by vcbfo13 with SMTP id fo13so1544530vcb.0 for ; Mon, 07 Nov 2011 07:56:47 -0800 (PST) Received: by 10.52.98.227 with SMTP id el3mr26988764vdb.8.1320681407105; Mon, 07 Nov 2011 07:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.112.169 with HTTP; Mon, 7 Nov 2011 07:56:26 -0800 (PST) In-Reply-To: References: From: Eli Bendersky Date: Mon, 07 Nov 2011 15:57:00 -0000 Message-ID: Subject: Re: why does -fno-pic coge generation on x64 require the large model? To: Ian Lance Taylor Cc: gcc-help@gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00060.txt.bz2 On Mon, Nov 7, 2011 at 17:37, Ian Lance Taylor wrote: > Eli Bendersky writes: > >> I'm experimenting with generating PIC and non-PIC code on x64 Ubuntu. >> It's possible to generate non PIC code as follows: >> >> =A0 gcc -fno-PIC -mcmodel=3Dlarge -shared -c file.c >> >> However, I noticed that for other models (i.e. -mcmodel=3Dsmall, or by >> default, without the -mcmodel argument), the code being generated is >> not really suitable for PIC as it has problematic load-time >> relocations. >> >> My question is - why is the large model required to generate true PIC co= de? > > It's odd to try to create PIC while using -fno-PIC. =A0I think you must > have some goal in mind for what you want your generated code to look > like, but I don't know what that is. =A0It most likely does not correspond > to gcc's goal when using -fno-PIC, which is to not generate PIC. > As I read my question, I realize my intention has not been clear enough. When I wrote "not really suitable for PIC", I actually meant "not really suitable for a shared library". I will try to clarify: What I'm trying to see is how to convince GCC to generate NON-PIC code and link it into a shared library for x64. I only managed to do this with "-fno-PIC -mcmodel=3Dlarge", and I wonder why with other memory models it doesn't work out. I suspect this has to do with some artifact of x64's addressing modes for symbol offsets. I should also add that my intention here is just curiosity. I was trying to understand how PIC code works on x64, and got intrigued by the fact that GCC seemingly forces me to use PIC code for shared libraries on this architecture, unlike x86 where non-PIC code in shared libraries is fine. Eli