From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29359 invoked by alias); 8 Nov 2011 03:19:18 -0000 Received: (qmail 29344 invoked by uid 22791); 8 Nov 2011 03:19:16 -0000 X-SWARE-Spam-Status: No, hits=-1.3 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; Tue, 08 Nov 2011 03:19:03 +0000 Received: from eggs.gnu.org ([140.186.70.92]:41678) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1RNcDF-0004tE-1u for gcc-help@gnu.org; Mon, 07 Nov 2011 22:19:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNcDD-0003Is-Ua for gcc-help@gnu.org; Mon, 07 Nov 2011 22:19:00 -0500 Received: from mail-vw0-f41.google.com ([209.85.212.41]:42927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNcDD-0003Io-Oj for gcc-help@gnu.org; Mon, 07 Nov 2011 22:18:59 -0500 Received: by vws16 with SMTP id 16so51174vws.0 for ; Mon, 07 Nov 2011 19:18:59 -0800 (PST) Received: by 10.52.90.45 with SMTP id bt13mr29457790vdb.25.1320722339272; Mon, 07 Nov 2011 19:18:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.234 with HTTP; Mon, 7 Nov 2011 19:18:38 -0800 (PST) In-Reply-To: References: From: Eli Bendersky Date: Tue, 08 Nov 2011 03:19: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.212.41 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/msg00077.txt.bz2 >> 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. > > Yes. =A0If it were easy to permit non-PIC x86_64 code in a shared library, > gcc would do it. =A0But the only way to do that is, as you say, to use the > large memory model, which is relatively inefficient. > Yes, I realize this. Hence my original question - *why* is the large memory model the only way to do it? I know it's relatively inefficient, because it's the most general and flexible in terms of addressing. Why aren't the small & medium models flexible enough? > The x86 shared library loader has a kludge where pages that contain > non-PIC code are remapped and relocated, so every process ends up with > its own copy of each relocated page. This is provided for > compatibility with older libraries. x86_64 is a new architecture, so > it wasn't necessary to provide backwards compatibility for non-PIC > libraries. So non-PIC code on x86_64 is actually different from non-PIC code on x86? It *doesn't* need page relocation? What's non-PIC about it then, and again, why only the large memory model allows it? Eli