*.S files are not preprocessed in managed builds about cdt

[kisvegabor]

It's cleaner solution, thank you!

As far as I know *.s (lower case) files should not be preprocessed. Will gcc make a decision based on the extension?

[jld01]

As far as I know *.s (lower case) files should not be preprocessed. Will gcc make a decision based on the extension?

Yes.

[kisvegabor]

It's great that issue was being discussed!

I can't see the all the details and possible issues, however I can tell my use case in the hope that it helps to make a decision.

We are developing an embedded UI library which now has some *.Sfiles for multiple Arm architectures to speed up some critical operations. Mostly we are developing the UI library on PC where the content of the *.S files should be disabled by an #if ....

Generally speaking this issue happens for everyone who adds ASM to speed up some parts of the code on foreign architectures. I don't know how common this use can be.

[jld01]

Hi @kisvegabor, GNU as does not invoke the C preprocessor. In order to pre-process your test.S file, you will need to use gcc as the assembler Command and add -c to the Assembler flags option:

@jonahgraham and @Torbjorn-Svensson, we should discuss making this the default behaviour.

[kisvegabor]

Great, thank you John!

[Torbjorn-Svensson]

As far as I know *.s (lower case) files should not be preprocessed. Will gcc make a decision based on the extension?

Yes.

Hm. @jld01, do you have any reference where it states that gcc will make a difference on *.s and *.S regarding if preprocessing the content is performed or if the content is sent directly to as?

[jonahgraham]

@Torbjorn-Svensson I think that this doc covers it, quoted:

For any given input file, the file name suffix determines what kind of compilation is done:
...

file.s
Assembler code.

file.S
file.sx
Assembler code that must be preprocessed.

This can be manually set with -x language where language is assembler or assembler-with-cpp

[Torbjorn-Svensson]

@Torbjorn-Svensson I think that this doc covers it, quoted:

For any given input file, the file name suffix determines what kind of compilation is done:
...
file.s
Assembler code.
file.S
file.sx
Assembler code that must be preprocessed.

This can be manually set with -x language where language is assembler or assembler-with-cpp

Ah! That explains why our tool preprocesses .s files. Thanks for the clarification!

[Torbjorn-Svensson]

Hi @kisvegabor, GNU as does not invoke the C preprocessor. In order to pre-process your test.S file, you will need to use gcc as the assembler Command and add -c to the Assembler flags option:

@jonahgraham and @Torbjorn-Svensson, we should discuss making this the default behaviour.

I think it would make sense to use the gcc binary instead of gas for *.S files.

[jld01]

It seems there would be a migration issue to consider for existing projects where the assembler Command option has not been modified by the user but the Assembler flags option has been modified. In such cases, the command attribute of the assembler <tool> element is not present in the .cproject file. So the project would use the new assembler command from the revised toolchain description but would not pick up the new -c flag. We could probably use an IOptionDefaultValueGenerator to avoid this issue.

[jantje]

As discussed during the CDT call:
Given that the proposed fix requires a migration which may not be successful for the people who have had (and solved) this issue I ask whether it is smart to do the proposed fix.
Basically there is a known work work around for the CDT provided project types.
Other projectTypes probably do not have this issue.
Given this is about building assembly language files that need the preprocessor to be compiled properly I would expect this to be a rare case.
So I'm wondering: given all the drawbacks of the current proposed fix and given the likely hood of it happening: Is it worth implementing the current proposed fix?