From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1309 invoked by alias); 3 Mar 2015 02:28:02 -0000 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 Received: (qmail 1296 invoked by uid 89); 3 Mar 2015 02:28:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-yh0-f53.google.com Received: from mail-yh0-f53.google.com (HELO mail-yh0-f53.google.com) (209.85.213.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 03 Mar 2015 02:28:00 +0000 Received: by yhaf10 with SMTP id f10so16791809yha.8 for ; Mon, 02 Mar 2015 18:27:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.170.52.14 with SMTP id 14mr31037263yku.77.1425349678564; Mon, 02 Mar 2015 18:27:58 -0800 (PST) Received: by 10.170.133.137 with HTTP; Mon, 2 Mar 2015 18:27:58 -0800 (PST) In-Reply-To: <0E847550-2947-46C3-991C-2720641BC881@linaro.org> References: <000001d0548a$789a1bd0$69ce5370$@arm.com> <0E847550-2947-46C3-991C-2720641BC881@linaro.org> Date: Tue, 03 Mar 2015 02:28:00 -0000 Message-ID: Subject: Re: [PATCH][ARM]Automatically add -mthumb for thumb-only target when mode isn't specified From: Terry Guo To: Maxim Kuvyrkov Cc: Terry Guo , GCC Patches , Ramana Radhakrishnan , Richard Earnshaw Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00112.txt.bz2 On Mon, Mar 2, 2015 at 9:08 PM, Maxim Kuvyrkov wrote: >> On Mar 2, 2015, at 4:44 AM, Terry Guo wrote: >> >> Hi there, >> >> If target mode isn't specified via either gcc configuration option >> --with-mode or command line, this patch intends to improve gcc driver to >> automatically add option -mthumb for thumb-only target. Tested with gcc >> regression test for various arm targets, no regression. Is it OK? >> >> BR, >> Terry >> >> gcc/ChangeLog: >> >> 2015-03-02 Terry Guo >> >> * common/config/arm/arm-common.c (arm_is_target_thumb_only): New >> function. >> * config/arm/arm-protos.h (FL_ Macros): Move to ... >> * config/arm/arm-opts.h (FL_ Macros): ... here. >> (struct arm_arch_core_flag): New struct. >> (arm_arch_core_flags): New array for arch/core and flag map. >> * config/arm/arm.h (MODE_SET_SPEC_FUNCTIONS): Define new SPEC >> function. >> (EXTRA_SPEC_FUNCTIONS): Include new SPEC function. >> (MODE_SET_SPECS): New SPEC. >> (DRIVER_SELF_SPECS): Include new SPEC. > > Did you consider approach of implementing this purely inside cc1 rather than driver? > > We do not seem to need to pass -mthumb to assembler or linker since those will pick up ARM-ness / Thumb-ness from function annotations. Therefore we need to handle -marm / -mthumb for cc1 only. What am I missing? > The way GCC uses to find multitlib prevents us from doing this via cc1. The target options should be properly constructed for gcc driver to decide multilib path, which happens before cc1. For example, for command line "arm-nonee-abi-gcc -mcpu=cortex-m3 -o hello.axf hello.c", we need to figure out that -mthumb should be added inside the gcc driver, otherwise such command line works like "arm-nonee-abi-gcc -marm -mcpu=cortex-m3 -o hello.axf hello.c" and the arm mode multilib will be linked. Thus we have to do this in gcc driver rather than cc1. > Also, what's the significance of moving FL_* flags to arm-opts.h? If you had to separate FL_* definitions from the rest of arm-protos.h, then a new dedicated file (e.g., arm-fl.h) would be a better choice for new home of FL_* definitions. > I set up an arch/core<->flags map array for gcc driver to figure out whether the target is thumb-only. Those FL_* flags are needed for this map array. The arm-opts.h is used to share back end information with gcc driver. Normally we tend to minimize such information. That's why I just moved those FL_* flags rather than simply including the header file which has FL_* flags. But maybe it is a good idea to save FL_* into a separate file. I will try. BR, Terry