Different CFLAGS for arch and non-arch files.

Different CFLAGS for arch and non-arch files.

[Peter Bergner]

Hopefully someone can point me in the right direction here.
I need to use different CFLAGS options depending on whether
I'm compiling arch dependent code or arch independent code.
It seems the arch/XXX/Makefile only adds extra options to
CFLAGS and doesn't allow me specify options I want to apply
only to arch dependent code and others I'd like to apply
only to arch independent code.  Has anyone done such a thing?

I guess I'd like to have CFLAGS, CFLAGS_ARCH and CFLAGS_NONARCH
vars that would be set in the arch/XXX/Makefile and then break
up the SUBDIRS var in the toplevel Makefile into SUBDIRS and
ARCHSUBDIRS so we could iterate over them with the different
CFLAGS options (ie, CFLAGS + CFLAGS_NONARCH for the arch independent
files and CFLAGS + CFLAGS_ARCH for the arch dependent files).

My reason for doing this is that our new architecture's ABI
specifies the use of a TOC (table of contents) and we're running
into a TOC overflow problem.  I can use GCC's -mminimal-toc option,
but not for routines that will be called before relocation is turned
on (the global TOC contains virtual addrs of the private TOCs).
My idea is to compile all the arch dependent code without the
-minimal-toc option and all the arch independent code with the
-minimal-toc option.

Any clues on what I can/need to do would be appreciated.

Peter

--
Peter Bergner
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development
IBM Rochester, MN
bergner@us.ibm.com

Re: Different CFLAGS for arch and non-arch files.

[Peter Samuelson]

[Peter Bergner]
> Hopefully someone can point me in the right direction here.
> I need to use different CFLAGS options depending on whether
> I'm compiling arch dependent code or arch independent code.

Use the per-directory $(EXTRA_CFLAGS), and/or the per-file
$(CFLAGS_foo.o).  See also $(EXTRA_AFLAGS), $(EXTRA_LDFLAGS) and
$(AFLAGS_foo.o).  I suppose there ought to be a $(LDFLAGS_foo.o) for
completeness, but nobody has needed it yet.

Peter