From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2564 invoked by alias); 9 Aug 2011 23:26:22 -0000 Received: (qmail 2555 invoked by uid 22791); 9 Aug 2011 23:26:22 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Aug 2011 23:26:06 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 779D75C000 for ; Tue, 9 Aug 2011 16:26:06 -0700 (PDT) Received: from vmware.com (cmss.eng.vmware.com [10.20.123.116]) by mailhost3.vmware.com (Postfix) with ESMTP id 569C5CD98B for ; Tue, 9 Aug 2011 16:26:06 -0700 (PDT) Date: Tue, 09 Aug 2011 23:26:00 -0000 From: Jed Davis To: gcc@gcc.gnu.org Subject: An unusual x86_64 code model Message-ID: <20110809232606.GA29776@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-User-Agent-Host: Linux cmss.eng.vmware.com 3.0.0-1-amd64 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00197.txt.bz2 The vSphere Hypervisor (ESXi) kernel runs on x86_64 and loads all text and data sections (for the kernel itself and for modules) within a 2GB window that lives around virtual address 0x418000000000 (65.5 TiB). Thus, 32-bit absolute addresses won't work, but %rip-relative addressing is fine. Additionally, because this is a kernel, the usual issues of "shared text" that discourage text relocations are inapplicable. What this means in terms of GCC is: the usual small code model won't work, nor -mcmodel=kernel, because they assume signed 32-bit addresses. The large code model probably will work, but that turns everything into movabs and indirect calls, which is unnecessarily inefficient. The closest approximation is -fPIC or -fPIE, but that assumes we want to implement the PLT/GOT machinery in our loader, which we don't; it imposes overhead for no benefit. The existing workaround, which predates my personal involvement, is to use -fPIE together with a -include'd file that uses a #pragma to set the default symbol visibility to hidden, which suppresses the PLTness. That works on GCC 4.1, but with newer versions that no longer affects implicitly declared functions (which turn up occasionally in third-party drivers), or coverage instrumentation's calls to __gcov_init, or probably other things that have not yet been discovered. Also, it was never an ideal solution, except in that it didn't require modifying the compiler (at the time). Thus, I'm trying to find the right solution. My current attempt is to add an -mno-plt flag in i386.opt, and add it to the list of reasons not to print "@PLT" after symbol names. This seems to work, although I've only done minimal testing so far. But is that the right way to do that, do people think? Or should I look into making this its own -mcmodel option? (Which would raise the question of what to call it -- medsmall? smallhigh? altkernel?) Or is there some other way that this ought to be done? Thanks, --Jed