Even though assembly-language .s files aren't supposed to be run through
cpp, clearly all of these are being preprocessed (#include is a strong
indicator). A few potentially non-preprocessed files remain named .s.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Bit of filename cleanup which seems overdue. Most assembly language files come from contrib and those are consistently <something>.S. Most of these are for i386 or the linux_*.s files. Everywhere else is <something>.S. Notably AMD64, ARM64 and PowerPC don't have a single .s file besides the linux_*.s files.
.S has won the battle for favored assembly-language source filename pattern.
Note that it's not just a preference for one of two equivalent extensions, but .s and .S actually have a different meaning. The former uses/used the assembler directly, while the latter uses the compiler driver and passes the input through the preprocessor. This change may be [probably is] the right thing to do, but the motivation should be "these files are supposed to be preprocessed via the compiler driver" or more likely "these files are already being preprocessed via the compiler driver" via bespoke Make rules, and thus the .s to .S change is really making the extension consistent with the use.
sys/modules/linux64/Makefile | ||
---|---|---|
85 | this is strange - I'm not sure why the linker script had a .s extension in the first place |
Updating message as per @emaste's comment. Removing the renaming of the *.lds.s files since those do appear to be a distinct situation.