cpukit is built in BSP, and BSP custom, specific part of build tree but isnt built using BSP's spec file

[Jeffrey Hill]

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.

[Sebastian Huber]

BSP variants may be added in the new build system for each multilib.