Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. The following email

is long but I hate to lose the information so I am including it here.


> I am still fixing and recompiling but this is the issue that was not the
> result of another patch.  This is a fundamental build issue that I value
> your opinion on.

This is difficult issue (I.e. I have no destinct solution for it)

Background:

(gnu-) make's  implicit rules apply CFLAGS, CPPFLAGS, CXXFLAGS, ASFLAGS and
LDFLAGS (cf. make.info/Implicit Rules/Catalogue of Rules), only.

In brief:
CPPFLAGS .. passed to the c-preprocessor
CFLAGS ... passed to the c-compiler
CXXFLAGS ... equivalent to CFLAGS but passed to the c++ compiler
(Attention: CFLAGS is not passed to the c++ compiler)
ASFLAGS .. equivalent to CFLAGS, but passed to the assembler
LDFLAGS .. equivalent to CFLAGS, but passed to the linker

A bit oversimplifying, these make rules are as follows
.c.o:
    $(CC) $(CPPFLAGS) $(CFLAGS) -c
.cc.o:
    $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c
.S.s:
    $(CPP) $(CPPFLAGS)
.s.o:
    $(AS) $(ASFLAGS)

My reading of the documentation (make.info) is that {AS|AR|CC|CXX|CPP}FLAGS
are ment to be passed to the related tools directly, however examinating
the rule set of gmake (gmake -p -f /dev/null")  shows that many rules use
$(CC) instead of the related tools (eg. linker rules) etc.

I.e. these flags should not rely on being passed through cpp or gcc. With
gcc being the common frontend for all of these tools of a gnu-toolchain the
situation becomes difficult (Which option is passed to whom and which tool
really uses it?), because these variable can also contain the toolchain's
frontend (eg. AS=gcc, LD=gcc, CPP=gcc -E).

For some commonly used options the situation is quite clear:
* -g -> CFLAGS
* -OX -> CFLAGS
* -D -> CPPFLAGS
* -A -> CPPFLAGS

But where to add -m, -B, -specs, -qrtems_XXX ?
* -B, -specs, -qrtems_XXX are gcc-frontend options
* -m is a combinations of flags to go to different destinations, in many
(all?) cases, the following is valid
-m is expanded by gcc into a set of -D and -A options
-m is interpreted by cc1 as a machine flag to generate a specific
instruction set.
-m is interpreted by gcc as an implicit linker search path for multilibs to
set up calls to LD.

>From my point of view this indicates we can either destingush between these
different usages (= separately add -m to CFLAGS, LDFLAGS etc) or to add it
to CPPFLAGS and use gcc (the frontend) instead of calling each tool
directly (less error prone) -- I vote for CPPFLAGS, but I am not sure.

-----------------

Now, where to add CPU_CFLAGS?

AFAIS, in probably all cases CPU_CFLAGS contain -D -A, and -m options,
only.
* -D and -A are supposed to go to CPPFLAGS
* -mXXX options can have multiple meanings (It can be gcc, collect2/ld and
cc1/cc1plus option simultaneously)

Here, I made a mistake - I destinguished between CPU_DEFINES to be added to
CPPFLAGS and CPU_CFLAGS to be added to CFLAGS and CXXFLAGS (cf.
gcc-target-default.cfg), generally assuming CPU_CFLAGS are CFLAGS.

This breaks preprocessing *.S into *.i files because CPU_CFLAGS flags were
not added to CPPFLAGS. Hence *all* *.S were compiled without taking
-mXX-flags into account. The i960/cvme BSP was the only one which
explicitly checked for a specific -m flag (-mca) and refused to compile
without it -- all other CPUs/BSPs silently swallowed this.

IMO, we can either
1) add CPU_CFLAGS and CPU_DEFINES to CPPFLAGS, thus silently convert
CPU_CFLAGS's meaning into CPU_DEFINES (Alternative solution: rename
CPU_CFLAGS to CPU_DEFINES and merge CPU_FLAGS with CPU_DEFINES).
or
2) destinguish between CPU_DEFINES and CPU_CFLAGS. In this case we would
need to check the contents of each CPU_CFLAGS in custom/*.cfg and move the
some parts of the contents to CPU_DEFINES and keep other parts in
CPU_CFLAGS (CFLAGS must contain options for the c/c++-compiler only!).

Though Solution 2) is the clearer one, I implemented 1) which is the
simplier one (the patch below).

ATTENTION: This patch is small in size, but affects almost everything.

------------

Additional complications araise with linking:

Some BSPs call  LD and AS directly (esp. gcc-2.7 make-exe rules). If LD=gcc
then LDFLAGS are supposed to be gcc-options, but if LD=ld then LDFLAGS is
supposed to contain ld-options.

An analog thought is valid for AS, but luckily enough ASFLAGS is not used
of inside the whole source tree.

Most RTEMS' custom/*.cfg use $(CC) $(CFLAGS) to link with gcc-2.8 make-exe
rules. With the patch below (CPU_CFLAGS added to CPPFLAGS) this means
CPU_CFLAGS will not be passed to the linker, which is incorrect for
multilibbed CPU's.

gmake's default rule set contains a variety of rules for linking, all
ending up in calling $(CC) $(LDFLAGS) for linking at their very end.

IMO, this means we should use something like

LINK.o = $(CC) $(LDFLAGS) in gcc-target-default.cfg

+ modify all gcc-2.8 make-exe rules to use
$(LINK.o) .......

+ setup LDFLAGS according to the requirements of the above.

I.e. we should use $(CC) for linking instead of calling the linker (LD)
directly and set LDFLAGS = $(CPPFLAGS) $(CFLAGS) or similar.

0 files changed, 0 insertions, 0 deletions