From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15408 invoked by alias); 1 Apr 2012 19:33:57 -0000 Received: (qmail 15394 invoked by uid 22791); 1 Apr 2012 19:33:56 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 01 Apr 2012 19:33:42 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SEQWx-0000d7-N8 from Maxim_Kuvyrkov@mentor.com ; Sun, 01 Apr 2012 12:33:39 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 12:33:39 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Sun, 1 Apr 2012 20:33:37 +0100 Subject: Re: [PATCH, i386, Android] -mandroid support for i386 target MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="iso-8859-1" From: Maxim Kuvyrkov In-Reply-To: Date: Sun, 01 Apr 2012 19:33:00 -0000 CC: "H.J. Lu" , gcc-patches , , Jing Yu Content-Transfer-Encoding: quoted-printable Message-ID: References: <455FBC37-ADBD-48E2-8D8E-6EB3C7198A29@codesourcery.com> To: Ilya Enkovich 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-04/txt/msg00007.txt.bz2 On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote: >> As is, it appears this patch did not see much testing, I'm pretty sure i= t breaks building shared libraries and PIE executable for Linux. >=20 > I do not expect any changes in compiler behavior for non Android > targets. I bootstrapped and checked patched compiler on linux-x86_64. > I also built ptched compiler for Android target using NDK scripts. OK. >>=20 >> Here and in other instances below you use "GNU_USER_TARGET_" prefix. I = would prefer using a shorter "GNU_USER_" instead unless there is a good rea= son to add "TARGET" too. >=20 > The reason is that some macroses are defined in other files and I just > redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also > used for other targets (i.e. in linux-eabi.h). So I do not see a good > reason to change it everywhere or mix it with other prefix > "GNU_USER_". OK. >> Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". Presu= mably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you never= define it. >=20 > You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined > in gcc/config/gnu-user.h. OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined. >=20 >>=20 >>>=20 >>> /* A C statement (sans semicolon) to output to the stdio stream >>> FILE the assembler definition of uninitialized global DECL named >>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >>> index 73681fe..a832ddc 100644 >>> --- a/gcc/config/i386/linux.h >>> +++ b/gcc/config/i386/linux.h >>=20 >> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h i= s used for multilib-enabled x86 toolchains. Placing below definitions in i= 386/linux.h will not allow adding an Android as an additional multilib to -= m32/-m64 x86 builds. I improve on this situation I suggest: >> - rename i386/linux.h to i386/linux32.h (with corresponding change to co= nfig.gcc), >> - put below definitions to new i386/linux.h (remember to add license not= ice header to the new file), >> - include i386/linux.h from both i386/linux32.h and i386/linux64.h. >=20 > Android does not support x86_64 target and therefore I do not want > -mandroid support for this target. When Android supports x86_64 target > this change would be appropriate. The point is that one can build a toolchain for i686-linux-gnu that will su= pport both 32-bit and 64-bit multilibs. The 32-bit multilib will be used b= y default, and compilation for 64-bit user-space can be requested with -m64= option. Even though Android is not supported for -m64, such a toolchain c= an support Android as a additional "-m32 -mandroid" multilib. I.e., the to= olchain will have three multilibs in total: "-m32" (default), "-m64" and "-= m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, eve= n though by default it would compile for 32-bit target. Does this clear up= things? Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics