On Tue, May 25, 2010 at 9:56 AM, Paolo Bonzini <bonz...@gnu.org> wrote:
> On 05/25/2010 09:55 AM, Steven Bosscher wrote:
>>
>> 1) Group front end objects in Makefile.in under e.g.
>> ALL_HOST_FRONTEND_OBJS
>> 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
>> 3) Conditionally poison symbols in system.h
>>
>> For the last step, that would be e.g.:
>> #ifdef IN_GCC_FRONTEND
>> #pragma GCC poison GCC_RTL_H GCC_REGS_H ...
>> #endif
>>
>> Unfortunately, my Makefile-fu is insufficient to do step 2. There is
>> an implicit rule ".c.o:" that triggers no matter what I try, and I
>> don't want to add explicit $(COMPILER) rules for all the front end
>> objects.
>
> $(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND
>
> ?
Hmm, the following *almost* works...
--------------------- 8< --------------------
Index: Makefile.in
===================================================================
--- Makefile.in (revision 159808)
+++ Makefile.in (working copy)
@@ -1445,12 +1445,18 @@ OBJS = $(OBJS-common) $(OBJS-md) $(OBJS-
OBJS-onestep = libbackend.o $(OBJS-archive)
+# This lists all host objects for the front ends. Extra defines are passed
+# to the compiler for these objects.
+ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
+ $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
+
+$(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND
+
# This lists all host object files, whether they are included in this
# compilation or not.
-ALL_HOST_OBJS = $(GCC_OBJS) $(C_OBJS) $(OBJS) libbackend.o \
+ALL_HOST_OBJS = $(GCC_OBJS) $(OBJS) libbackend.o \
@TREEBROWSER@ main.o gccspec.o version.o intl.o prefix.o cppspec.o \
- $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) \
- $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \
+ $(ALL_HOST_FRONTEND_OBJS) $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \
mips-tfile.o mips-tdump.o \
$(GCOV_OBJS) $(GCOV_DUMP_OBJS)
--------------------- 8< --------------------
But for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
files, libiberty, and gcov-io.o, like so:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -DIN_GCC_FRONTEND -DGENERATOR_FILE -I. -Ibuild
-I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4/include
-I/opt/cfarm/mpfr-2.4.1/include -I/opt/cfarm/mpc-0.8/include
-I../../trunk/gcc/../libdecnumber
-I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I/opt/cfarm/libelf-0.8.12//include
-I/opt/cfarm/libelf-0.8.12//include/libelf \
-o build/genmodes.o ../../trunk/gcc/genmodes.c
The -DIN_GCC_FRONTEND is not passed to middle-end objects, so there
must somehow be a dependency on the generator files from the front
ends, that I don't see here.
I configured with "--enable-languages=c,objc,fortran". I don't see any
dependencies in the front end files:
# Target specific, C specific object file
c_target_ob...@c_target_objs@
# Language-specific object files for C and Objective C.
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \
c-ppoutput.o c-cppbuiltin.o \
c-objc-common.o c-dump.o c-pch.o c-parser.o $(C_TARGET_OBJS) \
c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
# Language-specific object files for C.
C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)
# Language-specific object files for Objective C.
OBJC_OBJS = objc/objc-lang.o objc/objc-act.o
# These are the groups of object files we have. The F95_PARSER_OBJS are
# all the front end files, the F95_OBJS are the files for the translation
# from the parse tree to GENERIC
F95_PARSER_OBJS = fortran/arith.o fortran/array.o fortran/bbt.o \
fortran/check.o fortran/class.o fortran/constructor.o fortran/cpp.o \
fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o \
fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o \
fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o \
fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o \
fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o \
fortran/st.o fortran/symbol.o fortran/target-memory.o
F95_OBJS = $(F95_PARSER_OBJS) $(FORTRAN_TARGET_OBJS) \
fortran/convert.o fortran/dependency.o fortran/f95-lang.o \
fortran/trans.o fortran/trans-array.o fortran/trans-common.o \
fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o \
fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o \
fortran/trans-stmt.o fortran/trans-types.o
I am guessing this comes in from the $C_TARGET_OBJS and other language
target objects. In the Makefile in the build directory I have this
dependency:
Target specific, C specific object file
C_TARGET_OBJS=i386-c.o
But unfortunately I cannot find the rule for this object.
Anyway, I don't think that having a dependency on C_TARGET_OBJS should
introduce a dependency on the generator files. Sure, the C_TARGET_OBJS
files may be generated, but that should just mean that the gen*.o
files must be compiled first. Now, somehow, they end up in the list of
front-end files.
Any suggestions how to debug this?
Ciao!
Steven
