Re: Traditional cpp and assembler, revisited

[Kurt Lidl <lidl%pix.net@localhost>]

On Thu, Dec 09, 2010 at 01:43:25PM +0000, Christos Zoulas wrote:
> In article <20101209013327.GA26476%britannica.bec.de@localhost>,
> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
> >Hi all,
> >last year we already had a discussion about -traditional-cpp in the
> >context of clang and the interaction with assembler. Since this is one
> >of the show-stoppers for building the system with clang, I would like to
> >revisit this and come to a decision. As discussed, there are esentially
> >three different options:
> >
> >(1) Require gcc or pcc for building .S files. Introduce a new ASM_CC
> >variable for this purpose and use it for COMPILE.S and the MKDEP rules.
> >
> >(2) Use the cpp from pcc and adjust the share/mk rules to allow .S -> .s
> >translations using it.
> >
> >(3) Stop using the C preprocessor for assembler sources and switch to
> >some other preprocessor like m4. This is more involved since it requires
> >changing assembler code that uses e.g. machine/asm.h. It can also lead
> >to some duplication between m4 macro library and C headers. Positive
> >effect is that it would force us to visit all assembler files (at least
> >for the architectures clang/llvm support). Things like DWARF unwind
> >frames could be added to improve debugging support.
> >
> >For legacy compatibility, (2) is the least amount of work and helps
> >other users of K&R-CPP like imake. (3) has its own merits. What is the
> >direction NetBSD wants to take?
> 
> I think we need a standalone cpp because other random things need it
> (like xrdb), so I'd go with 2.

I would bet that using cpp is faster than using m4 too.

-Kurt