Re: [PATCH][ARM]Automatically add -mthumb for thumb-only target when mode isn't specified

[Terry Guo <flameroc at gmail dot com>]

On Mon, Mar 2, 2015 at 9:08 PM, Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>> On Mar 2, 2015, at 4:44 AM, Terry Guo <terry.guo@arm.com> 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  <terry.guo@arm.com>
>>
>>        * 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.<gcc-mthumb-option-v5.txt>
>
> 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