[RTEMS Project] #2301: cpukit is built in BSP, and BSP custom, specific part of build tree but isnt built using BSP's spec file

[RTEMS trac]

#2301: cpukit is built in BSP, and BSP custom, specific part of build tree but
isnt built using BSP's spec file
-------------------------+-----------------------------------------
 Reporter:  johill       |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  4.11.1
Component:  Autoconf     |    Version:  4.10
 Severity:  normal       |   Keywords:  cpukit multilib custom spec
-------------------------+-----------------------------------------
 The nios2 soft-core processor is probably a bit of a different beast
 because it has many options when the FPGA programming is configured. It is
 probably therefore not a good context for the use of multilibs, although
 it is possible to enable them.

 For the nios2 RTEMS automated system configuration I must interrogate the
 Altera sopcinfo file to properly specify some of the nios2 cpu instance
 specific compiler flags such as {-mhw-div, -mhw-mul, -mhw-mulx}.

 An easy way to do this is to build some custom tools that need to run
 _only_on_the_host_ during the build. The source code for these BSP
 instance custom tools are easy to write if they include header files from
 the Altera generated HAL {system.h, linker.h}, when they are built. The
 Altera HAL needs to also be generated, but not installed, during the gnu
 build. It seems that this is the way that Altera intends for users to
 learn about system configuration based on how often their file formats
 evolve, and also based on lack of documentation for their sopcinfo file.
 Nevertheless, for many reasons we don't include Altera generated header
 files into any RTEMS BSP or cpukit source code.

 Currently this approach is difficult to fully implement because I must
 finish the interrogation for the CPU flags during the gnu build system
 configure phase when CFLAGS_OPTIMIZE_V and CPU_FLAGS are fetched from the
 custom .cfg file, and so I am unable to build some custom tools that need
 to run _only_on_the_host_ during the build at that time.

 However, during the preinstall phase it is easy to create a custom
 "bsp_specs_cpu" file like this.

 *[cpuspecs]:
 *[cpuspecs]: %(cpuspecs) -mhw-div
 *[cpuspecs]: %(cpuspecs) -mhw-mul
 *[cpuspecs]: %(cpuspecs) -mhw-mulx

 Which could be used in "bsp_specs" like this.

 %rename cc1 old_cc1
 %rename cc1plus old_cc1plus
 %rename lib old_lib
 %rename endfile old_endfile
 %rename startfile old_startfile
 %rename link old_link

 %include <bsp_specs_cpu>

 *cc1:
 %{!qrtems: %{old_cc1} } \
 %{qrtems*: %{old_cc1} %{cpuspecs} }

 *cc1plus:
 %{!qrtems: %{old_cc1plus} } \
 %{qrtems*: %{old_cc1plus} %{cpuspecs} }

 *lib:
 %{!qrtems: %(old_lib)} \
 %{!nostdlib: %{qrtems: --start-group -lrtemsbsp -lrtemscpu -lc -lgcc
 --end-group \
 %{!qnolinkcmds: -T linkcmds%s}}}

 *startfile:
 %{!qrtems: %(old_startfile)} \
 %{!nostdlib: %{qrtems: start0.o%s start1.o%s crti.o%s \
     crtbegin.o%s -e __start -u __exception_vector }}

 *link:
 %{!qrtems: %(old_link)} %{qrtems: -dc -dp -N}

 *endfile:
 %{!qrtems: %(old_endfile)} %{qrtems: crtend.o%s crtn.o%s}

 This works very nicely excepting that the cpukit isn't built specifying a
 spec file and so it could use the wrong instructions when generating code.
 Therefore its tempting to modify the RTEMS build like this.

  cpukit/aclocal/gcc-specs.m4 | 20 ++++++++++++++++++++
  cpukit/aclocal/prog-cc.m4   |  8 ++++++++
  cpukit/automake/compile.am  |  5 +++++
  3 files changed, 33 insertions(+)

 diff --git a/cpukit/aclocal/gcc-specs.m4 b/cpukit/aclocal/gcc-specs.m4
 new file mode 100644
 index 0000000..dd49bb9
 --- /dev/null
 +++ b/cpukit/aclocal/gcc-specs.m4
 @@ -0,0 +1,20 @@
 +dnl
 +dnl $Id$
 +dnl
 +dnl Check whether the target compiler accepts -specs
 +dnl
 +
 +AC_DEFUN([RTEMS_GCC_SPECS],
 +[AC_REQUIRE([RTEMS_PROG_CC])
 +AC_CACHE_CHECK(whether $CC accepts -specs,rtems_cv_gcc_specs,
 +[
 +rtems_cv_gcc_specs=no
 +if test x"$GCC" = x"yes"; then
 +  touch confspec
 +  echo 'void f(){}' >conftest.c
 +  if test -z "`${CC} -specs confspec -c conftest.c 2>&1`";then
 +    rtems_cv_gcc_specs=yes
 +  fi
 +fi
 +rm -f confspec conftest*
 +])])
 diff --git a/cpukit/aclocal/prog-cc.m4 b/cpukit/aclocal/prog-cc.m4
 index e8b27b5..8dae5de 100644
 --- a/cpukit/aclocal/prog-cc.m4
 +++ b/cpukit/aclocal/prog-cc.m4
 @@ -27,6 +27,14 @@ dnl check if the target compiler may use --pipe
  RTEMS_GCC_PIPE
  test "$rtems_cv_gcc_pipe" = "yes" && CC="$CC --pipe"

 +dnl check if the compiler supports --specs
 +RTEMS_GCC_SPECS
 +
 +AS_IF([test x"$rtems_cv_gcc_specs" = xyes],[
 +GCCSPECS="-B\$(PROJECT_ROOT)/lib/ -B\$(PROJECT_ROOT)/$RTEMS_BSP/lib/"
 +GCCSPECS="${GCCSPECS} -specs bsp_specs -qrtems_cpukit"])
 +AC_SUBST(GCCSPECS)
 +
  # Append warning flags if CFLAGS wasn't set.
  AS_IF([test "$GCC" = yes && test "$rtems_cv_CFLAGS_set" != set],
  [CFLAGS="$CFLAGS -Wall"])
 diff --git a/cpukit/automake/compile.am b/cpukit/automake/compile.am
 index 3d81426..0e43494 100644
 --- a/cpukit/automake/compile.am
 +++ b/cpukit/automake/compile.am
 @@ -2,6 +2,11 @@
  ## $Id$
  ##

 +CC = @CC@ $(GCCSPECS)
 +CXX = @CXX@ $(GCCSPECS)
 +CPP = @CPP@ $(GCCSPECS)
 +CCAS = @CCAS@ $(GCCSPECS)
 +
  AM_CPPFLAGS = @RTEMS_CPPFLAGS@
  AM_CFLAGS =
  AM_CCASFLAGS = @RTEMS_CCASFLAGS@

 I am thinking that hopefully this wont break any existing CPU architecture
 and or BSP because of several reasons.

 1) Perhaps typical BSPs included in RTEMS are only modifying the way that
 executables are linked, and we probably don't create executables during
 the cpukit build.

 2) Probably most of the spec files are noop implementation if qrtems isnt
 specified, and for the cpu kit I specify -qrtems_cpukit

 3) I am specifying -qrtems_cpukit so its easy to write a spec file that
 does different things when it is and isnt a cpukit build. We could I
 suppose also define -qrtems_cpukit_multilib in that specific situation, if
 it were important to break that situation out.

 In any case this is what I currently have implemented and I will need to
 look for plan B before I can merge my nios2 support if this type of change
 looks like a bad idea.

 I am therefore writing to the relevant RTEMS wizards for some guidance.

 Thanks for your consideration.

--
Ticket URL: <http://devel.rtems.org/ticket/2301>
RTEMS Project <http://www.rtems.org/>
RTEMS Project