From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15019 invoked by alias); 12 Dec 2012 20:56:46 -0000 Received: (qmail 14999 invoked by uid 22791); 12 Dec 2012 20:56:45 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FB_GET_MEDS,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from caibbdcaaaaf.dreamhost.com (HELO homiemail-a79.g.dreamhost.com) (208.113.200.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Dec 2012 20:56:37 +0000 Received: from homiemail-a79.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTP id 8539E7D4059; Wed, 12 Dec 2012 12:56:26 -0800 (PST) Received: from AMDP6 (81-234-195-35-no56.tbcn.telia.com [81.234.195.35]) (Authenticated sender: rdos@rdos.net) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTPA id 4D77A7D4074; Wed, 12 Dec 2012 12:56:25 -0800 (PST) Message-ID: <25AF4112D5BA47A390D31A2264A7D11A@AMDP6> From: "Leif Ekblad" To: "GCC Patches" Cc: "GCC Mailing List" References: <20121212163722.GA21037@atrey.karlin.mff.cuni.cz> <20121212183036.GB5303@atrey.karlin.mff.cuni.cz> Subject: x86-64 medium memory model Date: Wed, 12 Dec 2012 20:56:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-12/txt/msg00855.txt.bz2 I'm working on OS-adaptations for an OS that would use x86-64 applications= =20 that are located above 4G, but not in the upper area. Binutils provide a=20 function to be able to set the start of text to above 4G, but there are=20 problems with GCC when using this memory model. The first issue has to do with creating a cross-compiler that defaults to=20 medium memory model using PIC. While there are switches to achieve this on= =20 command line (-mcmodel=3Dmedium -fpic), this is inconvinient since everythi= ng=20 ported must be changed to add these switches, including libgcc and newlib.= =20 The cross-compiler instead should default to this memory model. One possibility to achieve this is to add a new .h-file in the=20 gcc/config/i386 directory. However, further inspection of the source=20 indicates there is no macro that can be redefined to achieve this. One=20 possibility is to add such a macro in gcc/config/i386.h, and implement it i= n=20 gcc/config/i386.c. Here is a simple patch to do this: diff -u -r -N gcc-4.8-20121202/gcc/config/i386/i386.h=20 gcc-work/gcc/config/i386/i386.h --- gcc-4.8-20121202/gcc/config/i386/i386.h 2012-11-23 17:02:10.000000000=20 +0100 +++ gcc-work/gcc/config/i386/i386.h 2012-12-08 12:17:40.000000000 +0100 @@ -86,6 +86,8 @@ #define TARGET_LP64 TARGET_ABI_64 #define TARGET_X32 TARGET_ABI_X32 +#define TARGET_MEDIUM_PIC 0 + /* SSE4.1 defines round instructions */ #define OPTION_MASK_ISA_ROUND OPTION_MASK_ISA_SSE4_1 #define TARGET_ISA_ROUND ((ix86_isa_flags & OPTION_MASK_ISA_ROUND) !=3D 0) diff -u -r -N gcc-4.8-20121202/gcc/config/i386/i386.c=20 gcc-work/gcc/config/i386/i386.c --- gcc-4.8-20121202/gcc/config/i386/i386.c 2012-12-02 00:43:52.000000000=20 +0100 +++ gcc-work/gcc/config/i386/i386.c 2012-12-11 21:43:48.000000000 +0100 @@ -3235,6 +3235,8 @@ DLL, and is essentially just as efficient as direct addressing. */ if (TARGET_64BIT && DEFAULT_ABI =3D=3D MS_ABI) ix86_cmodel =3D CM_SMALL_PIC, flag_pic =3D 1; + else if (TARGET_64BIT && TARGET_MEDIUM_PIC) + ix86_cmodel =3D CM_MEDIUM_PIC, flag_pic =3D 1; else if (TARGET_64BIT) ix86_cmodel =3D flag_pic ? CM_SMALL_PIC : CM_SMALL; else It can be used like this: +#undef TARGET_MEDIUM_PIC +#define TARGET_MEDIUM_PIC 1 Next, with this issue fixed, there is still another problem in libgcc when= =20 using a cross-compiler compiled with this memory model: ../../gcc-work/libgcc/. -I../../../gcc-work/libgcc/../gcc -I../../../gcc-wo= rk/libgcc/../include=20 -DHAVE_CC_TLS -o cpuinfo.o -MT cpuinfo.o -MD -MP -MF cpuinfo.dep -c=20 ../../../gcc-work/libgcc/config/i386/cpuinfo.c -fvisibility=3Dhidden -DHIDE= _EXPORTS In file included from ../../../gcc-work/libgcc/config/i386/cpuinfo.c:21:0: ../../../gcc-work/libgcc/config/i386/cpuinfo.c: In function=20 'get_available_features': ../../../gcc-work/libgcc/config/i386/cpuinfo.c:236:7: error: inconsistent=20 operand constraints in an 'asm' __cpuid_count (7, 0, eax, ebx, ecx, edx); ^ ../../../gcc-work/libgcc/static-object.mk:17: recipe for target `cpuinfo.o'= =20 failed make[1]: *** [cpuinfo.o] Error 1 make[1]: L=E4mnar katalogen "/usr/src/build-gcc-noheader/rdos/libgcc" Makefile:10619: recipe for target `all-target-libgcc' failed make: *** [all-target-libgcc] Error 2 My guess is that __cpuid_count uses 32-bit addressing when it should be=20 using 64-bit addressing. I have no patch for this as I don't understand wha= t=20 is going on here well enough, but __cpuid_count is defined in=20 gcc/config/i386/cpuid.h. In order to be able to continue to test the medium memory model I'd need=20 patches to be applied to fix these issues. Regards, Leif Ekblad RDOS Development