| Message ID | 4FB1427A.3090300@oarcorp.com |
|---|---|
| State | New |
| Headers | show |
On Mon, 14 May 2012, Joel Sherrill wrote: > There is a long explanation in the PR but the short > version is that although we fully intended to switch > the arm-rtems target from ELF to EABI we never > intended the target name "arm-*-rtemseabi*" to > become the preferred arm RTEMS target name. > We want all RTEMS target names to be of the form > <cpu>-rtems. Unfortunately, we screwed up > and arm-rtems is marked as deprecated in 4.7. Note that various testcases test for target arm*-*-*eabi* (or some similar form that would catch arm-*-rtemseabi* but not arm-rtems). It would be a good idea to move them to using the arm_eabi effective-target. (Some of those tests also explicitly list arm*-*-symbianelf*, an existing EABI target not matching the arm*-*-*eabi* pattern; some do not.)
Hi, what is the blocking point for the integration of these patches?
On 05/14/2012 08:51 PM, Joseph S. Myers wrote: > On Mon, 14 May 2012, Joel Sherrill wrote: > >> There is a long explanation in the PR but the short >> version is that although we fully intended to switch >> the arm-rtems target from ELF to EABI we never >> intended the target name "arm-*-rtemseabi*" to >> become the preferred arm RTEMS target name. >> We want all RTEMS target names to be of the form >> <cpu>-rtems. Unfortunately, we screwed up >> and arm-rtems is marked as deprecated in 4.7. > > Note that various testcases test for target arm*-*-*eabi* (or some similar > form that would catch arm-*-rtemseabi* but not arm-rtems). It would be a > good idea to move them to using the arm_eabi effective-target. > > (Some of those tests also explicitly list arm*-*-symbianelf*, an existing > EABI target not matching the arm*-*-*eabi* pattern; some do not.) > Thanks for the pointer. Do you suggest to change: /* { dg-do run { target arm*-*-symbianelf* arm*-*-eabi* } } */ /* { dg-do run { target arm*-*-*eabi* } } */ into: { dg-do run { target arm_eabi } } */ ? Or is it: /* { dg-require-effective-target arm_eabi } */ What is the difference between the last two? Who sets "arm_eabi"?
On 06/05/2012 05:19 PM, Sebastian Huber wrote: > Hi, > > what is the blocking point for the integration of these patches? > Ping.
On 06/12/2012 11:53 AM, Sebastian Huber wrote: > On 06/05/2012 05:19 PM, Sebastian Huber wrote: >> Hi, >> >> what is the blocking point for the integration of these patches? >> > > Ping. > GCC uses a *-*-*eabi patterns to destinguish EABI toolchains from other ABIs. Your endeavour contradicts the spirit behind this. That said, I am strongly against applying this patch, because it will break this strict separation and will introduce a need to special case the arm-rtems target. Ralf
On 06/12/2012 01:23 PM, Ralf Corsepius wrote: > On 06/12/2012 11:53 AM, Sebastian Huber wrote: >> On 06/05/2012 05:19 PM, Sebastian Huber wrote: >>> Hi, >>> >>> what is the blocking point for the integration of these patches? >>> >> >> Ping. >> > > GCC uses a *-*-*eabi patterns to destinguish EABI toolchains from other ABIs. > Your endeavour contradicts the spirit behind this. > > That said, I am strongly against applying this patch, because it will break > this strict separation and will introduce a need to special case the arm-rtems > target. I don't continue to argue with you about this topic since everything is said. You have the minority option here and it was decided by the rest of the RTEMS community to bring the ARM RTEMS tool chain back to the RTEMS structure and this is $ARCH-rtems$VERSION for the default target. We also don't introduce a special case for arm-rtems. This special case is already there for arm-symbianelf.
diff --git a/gcc/config.gcc b/gcc/config.gcc index 129e7db..671d64f 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -870,7 +870,13 @@ arm*-*-ecos-elf) tmake_file="arm/t-arm arm/t-arm-elf" tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp" ;; -arm*-*-eabi* | arm*-*-symbianelf* ) +arm*-*-rtemself*) + tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h" + tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems" + tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp" + use_gcc_stdint=provide + ;; +arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*) # The BPABI long long divmod functions return a 128-bit value in # registers r0-r3. Correctly modeling that requires the use of # TImode. @@ -885,6 +891,11 @@ arm*-*-eabi* | arm*-*-symbianelf* ) tmake_file="${tmake_file} arm/t-bpabi" use_gcc_stdint=wrap ;; + arm*-*-rtems*) + tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h" + tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi" + use_gcc_stdint=provide + ;; arm*-*-symbianelf*) tm_file="${tm_file} arm/symbian.h" # We do not include t-bpabi for Symbian OS because the system @@ -895,11 +906,6 @@ arm*-*-eabi* | arm*-*-symbianelf* ) tm_file="${tm_file} arm/aout.h arm/arm.h" tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp" ;; -arm*-*-rtems*) - tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h" - tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems" - tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp" - ;; arm*-*-elf) tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h" tmake_file="arm/t-arm arm/t-arm-elf" diff --git a/gcc/config/arm/rtems-eabi.h b/gcc/config/arm/rtems-eabi.h new file mode 100644 index 0000000..ced98a9 --- /dev/null +++ b/gcc/config/arm/rtems-eabi.h @@ -0,0 +1,29 @@ +/* Definitions for RTEMS based ARM systems using EABI. + Copyright (C) 2011 Free Software Foundation, Inc. + + This file is part of GCC. + + GCC is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published + by the Free Software Foundation; either version 3, or (at your + option) any later version. + + GCC is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public + License for more details. + + You should have received a copy of the GNU General Public License + along with GCC; see the file COPYING3. If not see + <http://www.gnu.org/licenses/>. */ + +#define HAS_INIT_SECTION + +#undef TARGET_OS_CPP_BUILTINS +#define TARGET_OS_CPP_BUILTINS() \ + do { \ + builtin_define ("__rtems__"); \ + builtin_define ("__USE_INIT_FINI__"); \ + builtin_assert ("system=rtems"); \ + TARGET_BPABI_CPP_BUILTINS(); \ + } while (0) diff --git a/gcc/config/arm/t-rtems-eabi b/gcc/config/arm/t-rtems-eabi new file mode 100644 index 0000000..f0e714a --- /dev/null +++ b/gcc/config/arm/t-rtems-eabi @@ -0,0 +1,8 @@ +# Custom RTEMS EABI multilibs + +MULTILIB_OPTIONS = mthumb march=armv6-m/march=armv7/march=armv7-m +MULTILIB_DIRNAMES = thumb armv6-m armv7 armv7-m +MULTILIB_EXCEPTIONS = march=armv6-m march=armv7 march=armv7-m +MULTILIB_MATCHES = +MULTILIB_EXCLUSIONS = +MULTILIB_OSDIRNAMES =
Hi Since patches in PRs don't get much attention, this is an email about the attached patches from Sebastian Huber and myself to correct the arm rtems target name situation. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 There is a long explanation in the PR but the short version is that although we fully intended to switch the arm-rtems target from ELF to EABI we never intended the target name "arm-*-rtemseabi*" to become the preferred arm RTEMS target name. We want all RTEMS target names to be of the form <cpu>-rtems. Unfortunately, we screwed up and arm-rtems is marked as deprecated in 4.7. These patches do the following: + rename arm-*-rtems* to arm-*-rtemself* + make arm-*-rtemself* deprecated + make arm-*-rtems* an accepted name for arm-*-rtemseabi* arm-*-rtemself* can disappear when the ARM elf targets are generally removed. Sebastian tested them and the results are at: http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00322.html http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00323.html http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00324.html RTEMS is very consistent across target architectures and this just slipped through. We handled switches from a.out -> coff -> elf in a similar manner in the past. I hope it is OK to merge this. Thanks.