Re: Traditional cpp and assembler, revisited

[christos%astron.com@localhost (Christos Zoulas)]

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.

christos